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ABSTRACT 


Underwater Acoustic Networks (UAN) have two immutable obstacles to 
overcome; and the hostile environment in which it must operate; the combination of the 
propagation speed of sound in water, and the latency in communication that this 
produces, and the dynamic nature of the water column with respect to its attenuation of 
the sound signal. These combined issues make it very costly and time consuming to 
setup a UAN just to test new protocols that may or may not be able to mitigate the 
limitations of this environment. There exists, then, a need for an ability to test a new 
protocol without the overhead of creating a physical UAN. The goal of this thesis is to 
provide a more hospitable, adaptable, flexible, and easily useable environment in which 
to test new protocols for UANs, as well as providing the ability for the Physics field to 
test new physical layer encoding. This simulation environment will provide the glue, or 


bridge, between the two disciplines by working as a common tool for both. 
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I. INTRODUCTION 


A. MOTIVATION 

Growth in remote maritime sensing and the employment of autonomous 
underwater vehicles has spurred the development and implementation of wireless 
underwater networks. Unlike traditional wireless networks, underwater networks use 
acoustic signals to carry data rather than electromagnetic (radio) signals. Many papers 
have been written regarding the use of acoustic signals to support underwater networks. 
Among these, Kilfoyle’s provides a good synopsis of the issues pertinent to underwater 
acoustic network (UAN) deployment [1]. Subsequent papers by various authors tend to 
focus on the development of more capable signal processing techniques to improve signal 
quality and data rate, and thus improvements in modem technology, or report on various 
experimental UAN employments. Prominent research organizations in the United States 
involved in this research include Massachusetts Institute of Technology, Woods Hole 
Oceanographic Institute, Northeastern University, Florida Atlantic University, University 
of Washington, and Space and Naval Warfare Systems Center (San Diego). The Naval 
Postgraduate School activity includes underwater vehicle command and control research 
and access control protocol analysis by the Mechanical Engineering and Computer 
Science Departments, respectively. Various commercial entities are active in the 
development of acoustic modems necessary to implement the underwater 


communications channels. 


UANSs have two immutable obstacles to overcome. The first is the hostile 
environment in which it must operate. This includes not only the purely mechanical 
impediments of electronic equipment operating in water but also our ability as humans to 
work in this environment in order to deploy them. The second is a combination of the 
propagation speed of sound in water, and the latency in communication that this 
produces, and the dynamic nature of the water column with respect to its attenuation of 
the sound signal. These combined issues make it very costly and time consuming to 


setup a UAN to test new protocols that may or may not be able to mitigate the limitations 


of this environment. There exists, then, a need for an ability to test a protocol without the 
overhead of creating a physical UAN, which would significantly hamper the progress of 
the testing. 


The goal of this thesis is to provide a more hospitable, adaptable, flexible, and 
easily useable environment in which to test new protocols for UANs, which is the 
primary focus of the computer science field, as well as providing the ability for the 
Physics field to test new physical layer encoding. This simulation environment will 
provide the glue, or bridge, between the two disciplines by working as a common tool for 


both. 


This thesis documents a simulation system that provides message distribution 
between simulated UAN entities. The system provides significant flexibility for 
modeling various protocols representing different layers of the UAN functionality. A key 
aspect of the model is its focus on reuse, where different protocol implementations or 
modeling techniques can be instantiated by the modeler in order to demonstrate or 
evaluate the performance of the protocols or techniques of interest without significant 


modification to the underlying message exchange mechanism.. 


In general, this thesis will provide an interface for researchers to test their layer 
protocols or models, such as link access protocols or signal propagation models by 


providing the simulation of a water environment and a definable UAN topology. 


B. DESCRIPTION 
1. Conceptual Layout 
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Figure 1. | Conceptual Model 


Figure | depicts a possible layout of the distributed model. Traffic is forwarded 
by the source node, via a TCP connection to the Central Host (CH), which models the 
properties of the physical medium and forwards the message to all appropriate simulated 
hosts. It is the CH that will also simulate the properties of the medium to be modeled. 
The utility of the CH is not related to the type of simulation but rather it has to do with 
omniscience. That is, it provides a god’s-eye view of the topology, something the 
simulated UAN nodes can only assess by way of received traffic or protocol 
implementations. The Central Host maintains the modeled location of all simulated hosts 
in the physical topology represen tation. 

2. Event Modeling 

Some discussion could be had here as to the applicability of discrete-event or 
time-based simulation within the UAN. Although this is of concern in modeling any 


environment, it is not relevant to the outcome of this thesis. The environment itself 
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would not care on what metrics events are to occur and nor should not the simulation. As 
a physical layer message distribution simulation, this thesis is only concerned with 
passing data to and from the medium and upper layers. Any distribution of data beyond 
that falls into the functionality of higher levels of protocol and is left to future work. 

3. Central Host Topology 

As noted above, the forwarding of messages between a source and all recipients is 
by way of the CH. The message is then forwarded, by the CH, to all hosts that would be 
within range of the source. Since the physical medium forwarding properties will be 
unique for each UAN host pair, a separate session between the CH and each simulated 
host is appropriate. Further, since it is not desirable for messages to be dropped by the 
forwarding mechanism in the hosting environment, TCP connections are most 


appropriate and are used. 


While the use of paired TCP messages (source-to-CH: CH-to-neighbors) adds a 
degree of artificiality to the overall model, its benefits outweigh that cost. Without a CH 
maintaining the god’s-eye view of the modeled topology each node would need to 
maintain a local copy. While this would allow distribution of the physical layer 
calculations it would require careful coordination of topology status between all hosts 
creating opportunities for inconsistencies in the distributed network topology 
representation, especially in the case where mobile hosts are included. The CH method 
allows for ease of implementation, as sessions only need to be established between 
individual hosts and the CH rather than between all simulated hosts. Thus, adding or 
removing hosts will be less difficult than without a CH. 

4. Distributed Host Topology 

One method of overcoming the need for a god’s-eye view, and thus the dominant 
need for a CH, would be for each node to periodically broadcast to all other nodes its 
current position. The timing of such broadcasts could be tied to the mobility 
characteristic of each node, thus stationary nodes would send a position update once (or 
very infrequently) while very slow mobile nodes would send a position update possibly 
every 500 milliseconds and fast moving nodes might send an update possibly every 100 
milliseconds or less. If this method were to be used to eliminate the need for a CH then 


every simulated UAN host must maintain a communication session with every other host. 
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UDP may be used for this session so long as the update interval is sufficiently small to 
ensure that the loss of an update will not result in significant skews with regard to 
propagation delay calculations. 

5. Implemented Topology 

Careful selection of the physical medium model, either via a CH or distributed to 
each simulated host, has significant impact on the implementation of the model. If the 
artificiality of a CH for topology management is acceptable then the implementation of 
mobility and dynamic host availability is significantly simplified. However, a hybrid 
turns out to be much simpler, specifically in the calculation of collision detection that is 
needed to properly emulate the water acoustic medium and will be discussed in further 
detail later. This thesis implements a Central Host model with some functional 
calculations being performed in each UAN node. This distributes parts of the workload 
whose calculation results are unique to each node and significantly unburdens the Central 
Host. 
C. HOSTING ENVIRONMENT 

It was a goal of this thesis to create a simulation environment that would allow for 
more than one simulated node to run on the same physical host computer. An entire 
topology can be simulated on one computer with the power and resources of that 
computer being the only limits to the number of simultaneous simulated nodes. It is 
assumed, and recommended, that in larger topologies that the CH is run on a dedicated 
computer. In larger topologies, the CH will need sufficient resources to maintain TCP 
connections to all simulated nodes. The host systems were Pentium 4 based PCs with at 


least 500 MB of RAM. 


To ensure guaranteed delivery within the hosting environment, a switched Gigabit 
Ethernet is used with the TCP connections between CH and host nodes. The propagation 
speed difference between acoustic signals and Gigabit Ethernet links provides the slack 
time for calculating message arrival times and collision events. This guaranteed delivery 
is essential and is the underlying assumption for the algorithms and calculations 


concerned with collision detection simulation. 


D. THESIS STRUCTURE 

The remainder of the thesis is organized as follows. Chapter II Background, 
provides the background of Underwater Acoustic Networking in general, this simulation 
environment, and the SAAM project from which it drew inspiration. Chapter III 
Simulation Design, details the design considerations for this simiulation. Chapter IV 
Simulation Implementation, details the specific implementation choices and explains the 


benefit or reason for each. Chapter V Conclusions and Future Work, is self-explanatory. 


Il. BACKGROUND 


A. CHAPTER OVERVIEW 

It is important that the reader understand the validity of this work. In order to 
ensure this, the history of UAN must be laid out. This will set the framework for 
discussions to follow and will include a definition of the problem, some participants in 
the arena of solving this problem and a selection of prior and current works in two 
different fields and how they apply to this thesis. The next sections will discuss the 
history, participants, work and direction, in that order and lay the necessary groundwork 
for the reader that is unfamiliar with the subject and explain the complexity and need for 
this work. 

B. HISTORY OF UNDERWATER ACOUSTIC NETWORKING (UAN) 

When was the concept of UAN first conceived? The only correct answer to that 
question is to acknowledge when the first person considered hearing anything under 
water. It may never be known if the first thought of underwater acoustic networking was 
from that one child intently listening to the thuds of his home while holding is breath 
underwater in the bath tub, or from the acutely aware teenager swimming in the river and 
hearing the levity of everyone around him. But it can be no later than the invention of the 


submarine. 


The first submarine was a mere toy compared to the machines of today. Although 
William Bourne first drew plans for one in 1578, it was Comelius van Drebbel who took 
his rowboat and wrapped it in waterproofed leather and remained submerged in the 
Thames River for three hours [2]. But Drebbel was most likely so excited, that all he 


could hear was his own heart pounding within his ears. 


The logical beginning then, would have to be at the time of the first military use 
submarine. This honor would go to David Bushnell in 1776. It was called the “Turtle” 
and was used during the American Revolution against British warships. From this point, 
submarine purpose and the need for underwater communication and _ surveillance 
continued to grow. It was the underwater telephone and then sonar that was the first 


venture into injecting man made acoustics into the water for a designed purpose. This 


purpose climaxed with the start of the Cold War and the need to keep track of enemy 


submarines at long range from American coasts. 


The Cold War, with all its submarine activity, sparked the first large-scale 
implementation of a UAN. The Sound Surveillance System (SOSUS) provided a 
detection capability of submarines using their faint acoustic signals [3]. With the end of 
the Cold War, priorities have changed and technology has advanced. Today threats and 
interest change too quickly to justify massive and stationary networks. Today’s military 
and commercial advantages lie in quickly deployable, highly adaptable and dynamically 


changeable networks for vehicles, sensors and monitoring devices. 


The research challenges described in the paper by Akyildiz, Pompili and Melodia, 
on Underwater acoustic sensor networks [4], offers a good overview of the UAN need 
and defines several uses in the following areas; oceanographic data collection, water 
pollution monitoring, offshore exploration, disaster prevention, navigation assistance and 
tactical surveillance. 

C. WHO’S WHO IN THE UAN ZOO 

It is not just militaries that have an interest in UAN, as do many international 
companies. Both have provided numerous grants to universities to conduct research for 
them, albeit more monies do come from a military interest as companies often worry 
about trade secrets and tend to conduct their own research. Nonetheless, these two large 
groups have asked for a lot of research to be conducted. This research includes sound 
propagation modeling, bandwidth utilization analysis, physical layer encoding, protocol 


analysis and many others in order to overcome the restrictions that are inherent to UANs. 


Maybe the largest worldwide company conducting research in this area and 
providing solutions is the Sercel Company. Although a worldwide leader in seismic 
acquisition that continues to design, manufacture and provide for a full line of integrated 
equipment for, specific to this thesis, ocean-bottom cabling and marine environments, 
they acquired instrumentation in 2004 necessary for creation of an Underwater Acoustics 
Division. This division specializes in underwater acoustics and Marine Instrumentation 
for Offshore, Research and the Defense Industry. They offer a Multimodulation Acoustic 


Telemetry System designed to transmit over vertical and horizontal channels for 


applications including bottom-fixed stations, AUV’s, ships, bouys, and acoustic 
networks. Systems like this will be very useful once made easily deployable and not cost 


prohibitive, not to mention a little less proprietary. 


There are also several universities that conduct extensive research in acoustic 
propagation models and underwater networking. Along with the Naval Postgraduate 
school there is The University of Texas at Austin, MIT and Georgia Institute of 


Technology, just to name few. All of these universities have conducted, or are currently 
conducting, research for various military interests from SPAWAR, NAVSEA, ONI and 


ONR. There were also at least two experiments conducted mainly by military interests and 
were the Fleet Battle Experiment-India (FBE-I) [5, 6] and the Autonomous Undersea 
Systems Network (AUSNET) [7]. 


The ASW experimentation for FBE-I, using Seaweb, focused on undersea 
acoustic network connectivity between the acoustic and radio frequency regimes, while 
incorporating existing ASW data formats into a theater tactical capability. FBE-I was the 
ninth in a series of CNO sponsored experiments coordinated by the Navy Warfare 
Development Command (NWDC). The NWDC Mission is to “Operationally examine 
innovative concepts and emerging technologies to identify advanced war-fighting 


capabilities for further development and rapid transition to the fleet.” 


The AUSNET is a project that addresses the need for ad-hoc self-forming 
networks that can operate in low-bandwidth undersea environment. The AUSNET is a 
STTR Phase 2 program addressing network protocols for undersea communications that 
is jointly sponsored by the National Science Foundation and the Office of Naval 
Research. Applications for underwater networks are limitless. The ability to form an 
acoustic network from different platforms, ranging from stationary sensors to unmanned 
autonomous vehicles, to submarines and surface ships, would allow a richly interactive 


environment for data collection, surveillance and data distribution. 


Many interests have been shown and can be grouped into three major areas; modem 
design, acoustic propagation equations and networking and protocol design, but can also be 
broadly placed into two general categories; that of the acoustic engineers and that of the 
computer scientist. The acoustic engineers are concentrating on the proper modeling of 


sound propagation in order to develop modems that can operate in all underwater 
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conditions, while the computer scientists are concentrating on simulations and protocol 


efficiency in order to develop a network that can operate in all underwater conditions. 


The problem then becomes that one does not directly support the other. The 
problem of underwater acoustic networking is currently being attacked from two distinct 
and often disjoint disciplines with no foreseeable meeting in the middle. It is correct to 
work on a problem from more than one angle, but knowledge of these angles may help each 
other and will only yield the best picture for solution when both are used together. 

D. WORKING THE PROBLEM FROM BOTH ENDS 

To work a problem from both ends, the ends must be defined. On one end there 
are the acoustic engineers with propagation equations that can take several hours to 
calculate. On the other end there are computer scientists with network simulations and 
protocol analysis running in discrete-event, compressed time. The problem is that one 
does not compliment the other. A calculation that takes several hours cannot be used in a 
real-time simulation and a simulation that can not be run in real-time, does not support 


protocol analysis in a truly dynamic environment. Currently, shortcuts are being taken, 


by both sides, which make the validity of their results questionable. 


For underwater networking to work, the impediments to the networking aspect 
must be solved. The research done by Xie, Gibson and Yang [8] suggest that both 
dedicated access and pure contention access offer improved network performance over 
collision avoidance techniques currently in use. However, this research cannot be 
completely validated without a simulation capable of modeling the time dependent and 
dynamic nature of UAN traffic. Tools are needed that can offer this simulation 
environment and model acoustic propagation with the accuracy of the equations from the 
acoustic engineers and the efficiency of the protocols from the computer scientists. This 
accuracy in propagation is necessary to properly evaluate the needed protocols to make 
underwater networking a sustained reality. This sustained reality means reliable delivery 
and usable bandwidth for a reasonable cost. The tool does not currently exist that can 
bridge the complexity of the acoustic model offered by the acoustic engineer and the 
protocol abstraction of the network offered by the computer scientist. However, several 


validation attempts have been made at the edges. 
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Two examples on the acoustic side are the Navy Standard Parabolic Equation 
model and the Monterey-Miami Parabolic Equation (MMPE), while two examples on the 
computer science side are offered from Sozer and Coelho. The Navy equation was 
developed by the Naval Research Laboratory (NRL) and is implemented as the standard 
acoustic modeling for the Navy [9] while Kevin Smith and Fred Tapper [10, 11] 
developed the MMPE. Both of these models are very robust, very specific to an area and 
very computationally intense, which does not lend them to real time simulations. On the 
other end, there is the design and simulation of an underwater acoustic LAN by Sozer, et 
al. [12] and an analysis of medium access control scheme for UANs by Coelho [13, 14]. 
Both severely simplify the propagation loss calculations, the first using frequency and 
background noise level, and the second using only static range. These models are 
effective for use in a network simulation for course protocol testing but, without the true 
propagation model representation, fine-tuning and truly accurate protocol testing cannot 
be performed and are typical of other solutions being offered. This remains the current 
shortcomings of the tools in this area as the divide of models and tools offered by 
acoustic engineers and computer science simulations remains un-bridged. That is, for 
propagation models to not overload the simulation the equation must be unduly distilled 
and simplified, or for a simulation to run the full calculations required by a precise 
model, it will not be able to run in real time. This leads then to the debate over Event 
based or Time base simulations and the pros and cons for each. Event based simulations 


could operate under these restrictions where time based simulations could not. 


Event based simulations are often very appropriate where performance of a 
protocol is desired, since the timing can be compressed. But no matter how useful they 
are in time utilization, discrete event simulations do not allow for input from external 
sources, only that of a pre-scripted simulation timelines. These external sources can be 
that of simulated or real sensors, vehicles or agents. These time constraints and real time 
interaction are not mandatory to have a working and complete model, but they are 
significant enhancements over existing tools and will aid greatly in future developments 
to solve the complex model of underwater acoustic communication. Also, it is desired to 
create hybrid environments of simulation and physical networks for extensive testing of 
physical modems and network protocols. Event based simulations can not accommodate 
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this requirement as events in real time are not always known and can not be planned for 


in a discrete manner. Therefore, a time-based simulation with external inputs is needed. 


Modeling underwater acoustic network message distribution is a severely 
complex problem. The previously mentioned paper [8] gives two particular issues that 
bear heavily on the problem: (1) The variability of the channel impulse response, which 
requires evaluation of the channel for signal propagation characteristics for each message 
transmitted; and (2) the extreme propagation delays characteristic of UANs, as compared 
to wired or radio-based networks, which complicates the detection and handling of 
message collisions. Both of these issues are dynamic and thus affect the medium in real- 
time, thus requiring a time-based model for evaluation that is also capable of taking input 
from external sources for dynamic attributes or propagation models. It is these external 
sources that will allow for the correct characteristics of the dynamic medium to be 


simulated in real time. 


Problem (1) above is complex and as suggested in [8], will likely result in the use 
of a server farm to obtain a timely result. To utilize this server farm, the capability of 
external input is required. A previous thesis by Diaz-Gonzalez [15] has addressed the 
issue of simplifying this calculation but to also retain a more realistic propagation model 
than those proposed by Sozer and Coelho. This simplified method is a compromise 
between calculation precision and the processing power required to calculate it. It is able 
to be used directly within a simulation with promising results and takes the process much 
closer to reality. This calculation, however, is still limited in its ability to allow for 
changes during testing and does not support the dynamic need of physical layer 


designers. 


Although problem (1) above appears to be solved, at least in a limited but usable 
manner, it is not extensible to a mobile topology simulation or that of one that is part 
simulation and part actual physical network. That is, it will work fine for completely 
static topologies of stationary nodes in calm waters. This does not allow for mobile 
nodes or more than minor node variances in stationary node position, as shown in [15] to 
cause significant temporal differences. Also, using Sozer’s or Coelho’s methods would 


seem to solve problem (2) above but only succeeds in providing a gross estimate of the 
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solution. To obtain an accurate evaluation of a networking protocol or coding scheme, 
each must be tested within the effectiveness of the other. This can only be accomplish 
within a simulation tool that allows real time dynamic acoustic propagation modeling as 


well as network protocol testing. 


A flexible tool, taking external inputs, would allow the testing of new physical 
devices as well as multiple protocols by integrating the two disjoint knowledge areas of 
signal processing modeling of underwater acoustics and time-based computer network 
simulation. It is this capability that this thesis hopes to capitalize upon and limit the need 
for expensive field experiments. 

E. DIRECTION 

As laid out above, neither the acoustic engineer nor the computer scientist can 
solve this problem of underwater networking single handedly. This system concept has 
been described in detail in [8] but with no current implementation. This thesis is the first 
attempt at implementing the previously discussed model. This implementation of a 
testing environment, a useful tool, or a simulation that can use the precise propagation 
equations currently available; that can run in real time to evaluation how a protocol can 
handle all situations and be able to take input from the real world, or that of physical 
networks that are involved in the testing, will allow researches from both sides to quickly 
integrate and evaluate theirs ideas together. This tool could be the glue between the two 
communities of physics, with its acoustic engineers and modem designers, and that of 


computer science, with its network and protocol analysis. 
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Ill. DESIGN 


A. CHAPTER OVERVIEW 

Unlike traditional wireless networks, underwater networks use acoustic signals to 
carry data rather than electromagnetic (radio) signals. Unfortunately, the underwater 
acoustic environment induces severe limitations on the usability of a UAN. Two of the 
key limiting factors are severe propagation delays, associated with the approximately 
1500 meters per second propagation rate of the acoustic signal in seawater, and 
constrained bandwidth, due to extreme attenuation of frequencies above 50 Kilohertz 
over any appreciable distance, normally about 1000 meters [16]. Further, the Omni- 
directional nature of acoustic water channels leads to the same hidden terminal, exposed- 
station, and near-far problems associated with traditional (radio-based) wireless 


communications. 


To address these latter issues, a wireless network typically implements a form of 
collision avoidance access control to coordinate the transmissions of multiple users. 
Such techniques employ the exchange of “handshake” messages, which grant the use of 
the medium to a single user while informing other users within range of the intended 
recipient of the pending transmission. One such example is the RTS-CTS used in the 
802.11 protocol. But this “handshake” creates significant overhead, in a high latency 
medium, that dramatically reduces throughput of a UAN. This then requires new 


protocols to be created and tested. 


This chapter will investigate the different design options to best solve the problem 
of simulating an acoustic water medium and how to simulate message handling and 
collision detection. These options should provide for as much distributed processing and 
functionality as possible while providing the user with a clean and diverse tool in which 
to run protocol simulations. 

1. Key Components 

There are two distinct functions to consider, Simulation Control and Physical 
Layer implementation. Simulation control consists of setting up TCP communication 


sockets between nodes and providing an interface between channel simulation code and 
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the physical layer model implementation. Physical Layer implementation consist of 
properly representing the acoustic behavior in a given water column between two points. 
This acoustic behavior, or Acoustic Propagation Model, also depends on _ the 
characteristics of the sound, and therefore, the physical device (or acoustic modem) 


characteristics used for underwater communications. 


These two functions are not mutually exclusive. In order to provide the least 
amount of latency induced by the implementation, it will be necessary to tightly couple 
and streamline the two functions. This will most likely produce an implementation that 
can not be separated functionally but is a sequence of highly optimized, in-line code. 
This will provide a tool with minimal simulation overhead and be able to run on the most 


standard of current computers. 


There are also two logical environments to consider to aid in understanding the 
intricacies of this work, the simulated environment and the hosting (supporting) 
environment. The simulated environment is just that, simulated, and consists of just the 
network topology created by the user and its relation to the water medium. The hosting 
environment is the actual computers and network on which the simulated environment is 
created and run. This can be as minimal or expansive as the user sees a need to run. 
Several points of implementation are addressed later, as a result of the difficulty of 
simulating a water medium acoustic environment. 

2. Possible Design Models 

The purpose of this work is not to implement any protocols but to create a 
simulation in which to test protocols for a high latency medium. This simulation must 
emulate the water medium in as many aspects as possible. The better the simulation the 


more reliable the results will be. 


One goal of this work was to create a simulation that could run on the most 
common of computer networks. This would allow for continued use of previous 
investments and expedite simulation setup and usability. There are two distinct models 


that would accomplish this goal, the centralized model and the distributed model. 


The centralized model is a viable option only if a high performance computer is 


available or the simulation is not too complex in network topology, measured by the 
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number of simulated nodes in the network. A single computer can host the Simulation 
Control and the simulated Nodes as long as the overhead of processor state switching 
does not inject an artificial latency. A centralized model would also have perfect 
knowledge needed for collision detection; however, it would require a rather large 
structure to hold the many neighborhood conditions that relate to collision detection 
described later in this chapter. This model is ideal with respect to user interface, ease of 
setup and running, topology view and time synchronization but may require an unusually 


powerful computer on which to run. 


The distributed model is a more viable option to run across an existing network 
and investment, which satisfies one goal of this work. The structures of collision 
detection are much simpler when only related to one simulated node. Here the 
distributed model makes better use of existing resources by not requiring specifically 
high performance computers. This model would not be as easy to setup, as the 
simulation would need to be loaded for each simulated node. This requirement would 
basically move a function of the centralized model to the user of the simulation and 
require him to coordinate the loading of information to each simulated node. This would 
also apply each time any changes to the topology where made. This model is ideal only 
in the matter of using lower cost networks that may already exist but would require more 
complex implementation in terms of the actual simulation core implementation, and loss 
calculations without a central topology view being held to determine propagation losses. 


3. Design Model Used 
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Figure 2. Hybrid UAN Model 
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Network topology view is much simpler to maintain as a gods-eye view and is 
incorporated in the centralized model’s functionality resident in Simulation Control (SC). 
This gods-eye view also leads to incorporation of the propagation delay and loss 
calculation functionality into SC. Since it is much simpler to maintain topology 
information in a single location, it is also simpler to maintain neighborhood information 
in the SC and, thus, the propagation delay and losses from any node to any other node. 
The SC also remains the central point for Layer 2 Application connection requests. It is 
assumed that the SC location will always be known and that this simplifies this sequence 


of events. 


To ensure continuity between different programming languages that might be 
used as a layer two process, an importable object is provided that, once instantiated, will 
handle the simulation connections for that user as well as translate data from format of 
the message forwarding layer, analogous to the acoustic physical layer, to the Layer 2 
process format and vice versa. This interface is defined in the use of two method calls to 
the interface object, send and receive. The send method allows the layer two process to 
pass data to the simulation while the receive method allows the process to retrieve data 
from the simulation. This interface object handles all data transformation and assumes 
that any process that instantiates it, can operate with byte arrays. The data format, to and 
from a layer two process is standardized as byte arrays with the format conversion to and 
from the simulation being handled completely by the interface object internally. The data 
format change, from the layer two process to the simulation and vice versa, is handled 
within the interface object and will receive from and pass back to the layer two process, a 
byte array. It is reasonable to assume that all programming languages that might use this 


interface can operate with byte arrays. 


The Node portion of the simulation can run on the same physical host as SC, or a 
separate computer, and performs all collision detection since all aspects of a message 
collision is relative only to the receiving node. The simulated node is the only point of 
connection and communication to and from the layer two process, while also maintaining 
a separate communication connection to the SC for data flow within the simulation. This 
unburdens the SC and distributes processing power requirements over as many physical 


machines as are available to run the simulation. 
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4. Definition of “channel” 

For further discussions, the term “channel,” will refer to a set of unique acoustic 
conditions in which communication between two Nodes occurs. The combined effect of 
the unique properties of the water column are most directly applicable to this research in 
terms of link propagation delay; acoustic signal loss, and thus effective range; and link 
bandwidth. Hereafter, we consider these three values as they affect this simulation 
environment the most and may be the data returned from an external calculation. 

B. DEFINING THE OBSTACLES 

Simulation of a wireless environment within a wired hosting environment 
highlights several issues with respect to how to actually simulate propagation and 
transmission delays, and the proper representation of collisions within the physical 
medium (collision detection). While the computations of the acoustic propagation, which 
will provide channel loss values, are complex, these calculations have already been 
developed and may be computed internally or externally, as suits the goal or purposes of 
the particular simulation user. Physical Medium Collision Detection (PMCD), however, 


is handled within the simulation. 


Collisions, in the physical medium, result when a receiver receives more than one 
signal, at any given instance in time, without the ability to distinguish between each of 
the different signals. And although a different mechanism, the same networking 
condition results when the receiver is blanked, due to its own transmission status, during 
a time that a signal was present in the medium to be received. In the actual environment, 
both of these conditions would simply result in either no signal or a garbled or 
unrecognizable signal that may or may not get passed up to the upper layer depending on 
implementations of error correction and encoding within the physical layer being 
simulated. It is these conditions that must be represented correctly to properly simulate 
the water medium. 

1. Propagation Delay 

Propagation delay in water creates an issue with current protocol timing schemes. 
With the nominal speed of sound through water of 1500 meters per second, and the 
typical UAN range of 1000 meters, there is a one-way propagation delay of 667 


milliseconds, as illustrated in Figure 3. That is, the time between when a bit of data 
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leaves a transmitter until that same bit of data reaches the receiver 1000 meters away, is 


667 milliseconds. This is more than 4 times the average RTT of the Internet today. 
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Figure 3. Propagation Delay at 1500 m/s 


As discussed in earlier chapters, loss calculations can be intense, due to acoustic 
propagation model complexity, and not typically suitable for a time-base simulation. 
This then requires the use of less precise models of propagation, also discussed 
previously, to maintain this time-based simulation within the bounds of the minimum 
propagation delay as defined by the network topology and acoustic conditions where this 
network is located. In the simplest form, propagation delay is a function of sound 
propagation rate and distance. The loss calculation determines the possible reception 


range of a signal; given a particular minimum receive signal level or Signal-to- 


Interference/Noise-R atio (SINR). 


There are three possible design scenarios to accomplish these calculations. The 
first is that all calculations are completed prior to allowing any simulation traffic to flow. 
This would allow for the more complex calculations but would limit the acoustic channel 
conditions to a static state for the duration of a given simulation. The second is that less 
complex calculations are computed for each message to be sent within the simulation. 
This method allows for a limited dynamic set of acoustic channel conditions. This option 
would only be limited by the computing power of the physical hosting computer on 
which the Simulation Control is running. The third is for calls to a propagation modeler 
outside of this simulation. This would allow for the use of massive external processing 
power, possibly a server farm, to provide the answers to the complex propagation models 
within a time bounded by the requirements of this time-based simulation. The last 
method would also allow for referencing experiential data catalogued at various research 


agencies. 
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This work implements the first method, static calculations prior to simulation, but 
incorporates a completely modular design so that the second or third method can be 
implemented in the future by only changing one method within this simulation. This 
calculation provides the loss values and propagation delay to the SC. This is handled 
strictly within the SC where the neighborhood topology is formed based on the loss value 
returned; and a packet is not sent to the destination until the propagation delay has 
elapsed. 

2. Transmit Time 

Transmit time is tracked and used to calculate the beginning of the collision 
window. This tracking is only needed due to the difference in the speed of the hosting 
environment and that of the simulation environment, due to the high latency of the water 
medium being simulated. It is possible that multiple packets will be received, in the 
hosting environment, during the simulation time of even one message. This time is the 
starting point for calculations of propagation delay, transmission rate, transmission 
window and collision window. It is assumed that all hosting computers used in the 
running of a given simulation, will have system times synchronized in some matter. This 
allows for the transmit time of each packet to be set to the time that the simulation 
receives it from the layer two connection. This packet transmit time is then checked by 
the SC and modifies the simulated propagation time by any delay that might have already 
occurred due to communication lag from the Node to SC. This communication lag is 
assumed to be negligible due to the magnitudes of difference in speed between the 
hosting environment and the simulated environment but is implemented in this way to 
allow for use of slower hosting environments when necessary. 

3: Transmission Rate 

Transmission rate can be different for each channel defined and therefore must be 
accounted for and tracked for each packet flowing within the simulation. This is 
accomplished with the use of channel IDs and is set within each packet, by the simulated 
node that transmitted it as to which channel a given packet was transmitted on. If a 
receiving simulated node can receive on the channel that a packet was transmitted, then it 
will know the rate and calculate it accordingly. Transmission rate, with message length, 


defines the duration of the collision window. 
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4. Collision Detection 

The Collision Detection Finite State Machine (FSM) represents the algorithm of 
collision detection used in the CollsionDetectionThread class, as illustrated in Figure 4. 
The idle state represent that no messages are currently being received. This can be that 
no messages have been received, as would be the case at the start of the simulation, or 
that the collision window has expired. The transition from idle to busy occurs when a 
message is received. The busy state represents a message currently being received that 
has not collided with any other message. The transition from busy back idle occurs when 
the collision window expires and no collision has occurred and the message is passed to 
the upper layer. The transition from busy to collision occurs when the collision window 
has not expired prior to another message being received, thus a collision has occurred. 
Any other messages received while in the collision state will cause a transition back to 
itself and remain in the collision state until the collision window has expired. The 
transition from collision to idle occurs when the collision window has expired and all 


collided messages have been dropped. 
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Figure 4. Collision Detection FSM 


The core coding and implementation of the physical layer collision detection was 
a significant obstacle of this work. The proper representation of a physical collision is 
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imperative for a correct and useful simulation. To determine if a collision has occurred it 


must first be determined if any receive window overlaps another receive window or that 


of a transmit window for a specific channel, as illustrated in Figure 5. 


An example of a four message situation might be as follows: 
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Figure 5. — Collision Window Overlap Per Receiving Node 


Message | collides with messages 2, 3 and 4; message 2 only collides with 
messages 1 and 4; message 3 also collides with messages | and 4 while message 4 
collides with messages 1, 2 and 3. As can be seen from the figure, if any message 
reception begins after the start of another message but before the end of that message a 


collision occurs and both messages are subject to corruption, and thus rejection. 


To calculate a collision window, the transmit time, transmission rate, size (length) 
of the signal and propagation delay must be known. Transmission rate and propagation 
delay are channel dependent. The collision window is a duration calculated from the 
length of the signal and the transmission rate of the channel. The transmit time with the 
propagation delay, defines the start of the collision window, relative to the receiving 
node. That is, if two nodes transmit the same signal, on the same channel, to the same 
destination node, at the same time; if one of the transmitting nodes is far enough away 
from the intended destination node, then the two signals will not collide and will be 
properly received. This is true due to the fact that propagation delay, in its simplest 
terms, is a function of the speed of sound through water and the distance to travel. So, as 


long as the propagation delay for one of the messages is greater than the sum of 
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propagation delay and transmission delay for the other message, then the two messages 


will not overlap and, thus, will not collide; as illustrated in Figure 6. 
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Figure 6. | No Collision with the Same Receiver 


C. STRUCTURE 
For this simulation environment, functionality is divided between the Simulation 
Control (SC) and the simulated node. The SC is the focal point of control, simulated 
node communication and medium emulation, as well as conducting the UAN topology 
setup. The SC also accepts requests from applications to connect to the simulation acting 
as a layer two or higher protocol. A simulated node maintains communication with the 
SC and a layer two protocol application and performs collision detection with respect to 
messages sent and received. This division of labor, intended to be as distributed as 
possible, is further defined below. 
i. Functionality of the Simulation Control 
The SC handles the following functions: reads a network topology from a file; 
estimates propagation loss (internally or externally); determines each nodes 
neighborhood topology from the network topology and channel loss _ estimates; 
establishes and maintains communications with all simulated nodes; handles request for 
layer two connections; and simulates propagation delay. 
a. Reading in the Network Topology 
Once the user selects the file to read, the SC parses this XML file and 
builds the network topology for the simulation and stores this information in a network 


information object. 
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b. Setting up the Neighborhood Topology from the Network 
Topology 


Once the network topology has been created, all node locations are known 
and all nodes are compared to all other nodes based on channel loss calculations. If it is 
possible for a node to hear the transmission of another node based on the estimated signal 
range as derived from the propagation loss estimate, then it is considered in the 
neighborhood for that node. This relation will not necessarily be symmetric as acoustic 
channel conditions are not bi-directional and may prevent communication in one 
direction between a pair of nodes. Further, depending on the complexity of the loss 
calculation employed, this value may be dynamic and result is periods of discontinuity 
between neighboring hosts based on such factors as node mobility or wave motion. 


CG Establishing and Maintaining Communications with each Node 
within the Simulation 


The SC will wait for connections to be made from as many nodes as are 
defined in the network topology. Separate communications are maintained for each 
simulated node. Once all connections are made, simulation setup continues with each 
node being assigned its identity within the simulation based on the network topology 
defined. 


d. Handling Requests for Layer 2 Functionality and Connection to 
the Simulation 


A Layer2 Application sends a request for connection to the SC. The SC 
then forwards this information to the next available simulated node. 
e. Simulating Propagation Delay 
Loss calculations are determined from the propagation model and may be 
different for each direction of communication between each pair of nodes within a 
neighborhood. The SC will not forward a packet to a node until the propagation delay 
elapses, to ensure that the packet arrives at the node at the time that the first bit of the 
message would have arrived, as if in the actual environment being simulated. 
2 Functionality of Nodes 
The simulated node maintains communication with the SC and a layer two 
process. The simulated node also performs collision detection. If a collision occurs, the 


message is not passed up to the layer two process. 
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a. Handling Communications with the Simulation Control 

Communication with the SC is maintained with a TCP socket for 
guaranteed delivery and reliability. 

b. Handling Communications with the Layer 2 Process 

Each simulated node maintains communication with a layer two process 
using a TCP socket for guaranteed delivery and reliability. The layer two side of this 
communication is actually an interface object, provided by this work that encapsulates 
the TCP socket and provides a straightforward access to the socket’s stream objects. The 
layer two process actually sends and receives its data via this interface object, that it 
imported and instantiated as part of its application. 


CG. Performing Physical Layer Collision Detection in the Simulation 
in Order to Properly Represent It to the Layer 2 Process 


A Collision Event is simply defined as two overlapping receipts or a 
receipt during transmission on a simplex link. In either case, this model will not pass a 
message up to the layer two application. The key factors here are Transmit Time, 
Transmission Delay and Transmission Window. 

(1) Transmit Time and how it affects CD. The transmit time 
defines the start of this sequence of calculations as it starts the clock for the transmission 
window, receive window and collision window. 

(2) Transmission Delay and how it affects CD. Transmission 
Delay defines the duration needed by a receiver to receive a signal once the first bit 
arrives. It is a function of transmission rate of that channel and the received message size 
and defines the duration of a collision window. 

(3) Transmission Windows and how it affects CD. The 
Transmission Window only affects CD when a channel is designated as a transmitting 
channel. If a channel is able to transmit and receive, the transmit window becomes a 
collision window for its duration. 

D. COMMUNICATION 

The two commonly known models for communication are in-band and out-of- 
band communication. The out-of-band communication would require a second socket 
with which to communicate with each node. The overhead, of a second socket, was not 


desired. The serialized nature of network simulation setup and then running of the 
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simulation was very compatible with in-band communication, which also minimized the 


use of resources within the hosting environment. 


Simulation communication uses a serial adaptation of the in-band model. All 
communication originating from the SC (i.e. the setup) is accomplished first. Once the 
simulation is completely setup, this type of communication discontinues. The 
environment then runs purely as a simulation until termination. Communications from 
SC-to-Node, Node-to-SC, Node-to-Layer2 and Layer2-to-Node are all via TCP sockets. 
The TCP sockets provide a reliable delivery scheme to build the simulation upon. 


E. USER INTERFACE 


A GUI interface was considered but would have been utilized too little for the 
effort. Very little user input of data is required and is more effective to use a command 


line interface. 


Inputs required from the user are via command line and are as follows: the IP 
address and port number of the SC upon launching a Node; and the IP address and port 
number of the SC upon launching any application that instantiates the 


UAN.Helpers.Layer2Connect object to connect to the simulation. 


One GUI is used for the selection of an XML file that contains the network 
topology of the simulation, which is an input to the SC. 


F. DIRECTION 
This chapter has laid out the pros and cons of two different design models, the 


centralized and the distributed model. The strengths of both models were chosen to form 


a hybrid approach that will now be implemented and detailed in the next chapter. 


padi 
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IV. IMPLEMENTATION 


A. CHAPTER OVERVIEW 

The goals of this implementation were modularization, abstraction of message 
passing, distributed processes and functionality, non-blocking I/O and minimizing 
simulation overhead. Modularization of code provides for functionality that can be easily 
upgraded and enhanced when needed. Abstraction of the passing of information within 
the simulation, as objects, ensures that the underlying handling structure is not dependent 
on the type of messages to be handled. To ensure this tool can effectively run on the 
computers available in the most common network environment, it is necessary to 
distribute the processing power required and as a result the functionality, to lessen the 
maximum requirements of any computer to run this tool. This also helps to minimize 
simulation overhead. Simulation overhead is also considered any time a loop is required. 
To ensure that processes and threads do not induce undesired overhead, they are forced to 


yield when performing a busy-wait condition, such as a while-true loop. 


One significant issue is I/O. In order to guarantee message delivery, even using 
TCP connections, it is necessary to implement a non-blocking I/O scheme. Java provides 
for this in the nio.channel package since JDK 1.4.2, but to ensure as little simulation 
overhead as possible, this ability was implemented simply, with minimal code, using 


separate threads for each stream of a given socket. 


Modulation and abstraction was also enhanced by using Java as the programming 
language. The main reason for using Java, however, was to provide maximum portability 
and cross platform compatibility for this simulation tool so that its use would be as 
seamless as possible. The functionality of the Simulation Control (SC) is handled within 
the SimControl class while the Node functionality is handled within the NodeControl 
class. This chapter describes the classed developed under this thesis effort to implement 


this simulation. 


This work was coded in the NetBeans 5.0 IDE and is broken into four packages, 
UAN.Channels, UAN.Sim, UAN.Helpers and UAN.Node. 
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B. CHANNELS PACKAGE 

The UAN.Channels package contains the channels which are defined for a given 
simulation. The package contains four java classes, Channel.java, ChannelZero.java, 
ChannelOne.java, and ChannelTwo.java. 

1. Channel.java 

This class is a superclass for all channels and defines the minimum attributes of a 
channel needed to support the simulation. This class is constructed with; a name as a 
string, the transmit rate as an integer, the frequency as an integer, and the unique channel 
ID as an integer. This class also contains four public methods to return these values 


when needed. 


The subclasses of channel were only used to test the simulation. During 
simulation testing, things were kept simple and easy to calculate by using the same 
transmission rate for all channels. It is possible that all channels are identical with the 
only requirement being that each channel in the simulation has a unique channel ID. This 
allows for an over simplification of a channel to support simple simulation runs by 
allowing unique channels within the simulation that may be identical in the attributes that 
affect the simulation. That is, all of the transmission rates might be the same, but only 
the frequency or underlying encoding is different. If transmission rates did not change, 
then the collision window duration did not change and collision detection is not affected. 
However, the frequency and encoding would affect the loss calculation provided from the 
acoustic propagation model; but those calculations would have already been determined. 


Constructor public Channel (String name, int transmitRate, int 


frequency, int ID) 
Methods public int getTransmitRate() 
public int getFrequency () 


public String getName () 





public int getID() 
Table 1. Channel 


a. The getTransmitRate Method 


This method returns the transmit rate of this channel as an integer. 
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b. The getFrequency Method 
This method returns the frequency of this channel as an integer. 
CG. The getName Method 
This method returns the user defined name of this channel as a string. 
d. The getID Method 
This method returns the unique ID of this channel as an integer. 
2. ChannelZero.java 


This class extends the Channel class and is constructed by the user with only a 


name. This channel has a 1 Kbps transmission rate, a frequency of 4 Hz and a unique ID 


of 0. 


public ChannelZero(String name) 


super call super(name, 1*Kbps, 4, 0) 





Table 2. ChannelZ ero 


3: ChannelOne.java and ChannelTwo.java 
These two channels are identical to ChannelZero.java except for ID which is 
unique. These channels were built minimally to allow the simulation to run. It is 
expected that once this tool is utilized, that this package of channels will be enhanced. 
C. SIM PACKAGE 
The UAN.Sim package contains seven classes; SimCommsThread.java, 
SimControl.java, NeighborInfor.java, NetInfo.java, NodelInfo. java, 
SAXNetworkIn foParser java, SendDelayThread.java. 
1. SimControl.java 
This class contains the core of the Central Host functionality and contains a main 
method. The main method is a sequence of five calls that relate to logical parts of the 
Simulation Control functionality; readTopology(), neighborhoodSetup(), 
makeNodeConnections (), deployNodes(), listen4layer2(). 
a. The readTopology Method. 
This method uses the S4XNetworkInfoParser.java class to parse an XML 


that is chosen by the user at simulation startup. The network information is then held in a 


31 


NetInfo object. This method also calls a private method chooseFile that provides a GUI 
interface for the user to choose the desired XML file to load. 

b. The neighborhoodSetup Method. 

This method enumerates all the Nodelnfo objects, held in the Net¢Info 
object, using an inner and outer while-loop. This continues until the outer loop 
enumeration has no more elements. The outer loop enumerates all the nodes once, while 
the inner loop enumerates all the nodes once for each node of the outer loop enumeration. 
The outer loop builds the neighborhood for that node while the inner loop provides the 
next node to evaluate and determine a neighbor relationship. With each permutation of 
the inner and outer loops of nodes, a comparison is made as to whether this pair of nodes 
is within detectable range of each other, and if so, it is added to the hashtable within this 
NodelInfo object that contains this node’s neighborhood. 

CG. The makeNodeConnections Method. 

This method creates a server socket which to listen for node connections. 
It utilizes one while-loop to enumerate the Nodelnfo objects contained in the Net¢Info 
object to establish connections with all the nodes of the topology. Once a connection is 
established with a node, a new SimCommsThread is spawned with this socket and the 
node name. The new thread is then added to a hashtable that will contain reference to all 
the threads that the SimControl uses to communicate with the nodes. This hashtable built 
with the node name as the key and the communication thread as the object. 

d. The deployNodes Method 

This method uses a while-loop to enumerate all the Nodelnfo objects 
which now contain all the needed information. This information is then passed to the 
simulated node in a NODEINFO type packet through the forwardPacket method, which 
is only used by the SimControl since it originates the packet and is not part of the 
simulated topology. The proper communication thread is chosen by node name. 

e. The listen4Layer2 Method 

This method listens for UDP packets from a process or application that 
wishes to connect to the simulation with, at a minimum, layer two functionality. For 
simplicity of implementation, an empty UDP packet is used. A UDP packet already 


contains the IP and port of its origination and, therefore, needs no further data to include 
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this information. This method works with the Layer2Connect class in the UAN.Helpers 
package. When this method receives a UDP packet, it is assumed to come from the IP 
and port listening for UDP packets on the process requesting this connection, from the 
Layer2Connect class. It creates an Address object with the IP and port number from the 
incoming UDP packet. It then calls the forwardPacket method with this Address object, 
contained within a LAYER2 type packet object, to pass this request to the next node with 
a layer two connection. The simulated node further handles making this connection. 

f Helper Methods 

There are several private methods that are also implemented to cleanly 
divide functionality and ensure code readability. These are: chooseFile, nodeData, 
sendToNeighborhood, forwardPacket, calcLoss, and distance. 

(1). The chooseFile Method. This method provides a GUI for the 
user to choose the XML file containing the node characteristics to load. It utilizes the 
java file chooser class. 

(2). The nodeData Method. This method provides the interface for 
the SimCommsThread to pass data from SimControl to the simulated node. This method 
then calls the sendToNeighborhood method with the packet passed. 

(3) The sendToNeighborhood Method. This method enumerates 
through the hashtable of neighbors of the source node named in the packet. This source 
node name is retrieved by calling the getSrcName method of the Packet class. It then 
forwards this packet to each neighbor, of the source node, via the SendDelayThread class. 

(4) The forwardPacket Method. This method is only utilized 
during initial setup as all packets, during setup, originate from the SC and does not relate 
to a neighborhood based on source node. The SC is not in the topology. This allows for 
directly sending information to the desired node during setup. 

(5) The calcLoss Method. This method is the implementation of 
the ‘static loss calculations’ for this simulation. It takes latitude and longitude of a node 
pair in decimal degree format and returns the propagation delay in milliseconds after 
calling the distance method to determine the distance between the two entities. 

This method must be changed once a different loss calculation is 


implemented. 
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(6) The distance Method. This method calculates the straight line, 
cure of the earth, point-to-point distance between the two nodes. It returns this value to 
the calling method in milliseconds. This millisecond value represents the distance with 
respect to propagation delay. 

g. Testing Methods 

There are also four other methods included in the SimControl class but 
will not be discussed. These methods implement different testing and debugging tools 
and can be studied in the separately provided code if desired. 


2. SimCommsThread.java 
This class extends the java Thread class and handles the communication between 


the SC and a simulated node. 


lic SimCommsThread (Socket socket, String name) 
Methods lic void run ( 


blic void dataToNode (Packet p) 








aie private synchronized void dataToSim(Packet p) 


Table 3. ©SimCommsThread 


a. The run Method 

The run method is required when extending java class Thread. In this 
implementation, a while-loop is used to continuously listen for packets from the node. 
When a packet is received from the node connected to the socket this thread monitors, it 
is passed to the SC main process via a method a call to method, dataToSim (packet). 

b. The dataToSim Method 

The synchronized dataToSim method passes the packet to the SC via a call 
of the nodeData(packet) in the SinControl class. The method is synchronized to ensure 
safe passing of data, from multiple threads, to the SC. Prior to this, it sets the packet 
source name to the name of this thread, which is the same as the node name, by calling 
the setSrcName method in the Packet class. 

CG. The dataToNode Method 

The dataToNode(packet) method is called from the SimControl class. 
This method writes the packet to the object output stream of the socket that was passed to 
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this thread when this thread was created. The method forces the packet the packet to be 
forwarded immediately by calling the flush method of the output stream. 

3; NeighborInfo.java 

The NeighborInfo object contains a Nodelnfo object and a delay, in milliseconds 


as an integer, and is utilized by the SimControl class to build a neighborhood relative to 


each simulated node. 


public NeighborInfo(NodeInfo node, int delay) 
Methods public NodeInfo getNode () 
public int getDelay() 


Table 4. NeighborInfo 








a. The getNode Method 
This method returns this node as a Nodelnfo object. 
b. The getDelay Method 
This method returns the delay in milliseconds as an integer. 
4. NetInfo.java 
The NetInfo object contains all the information about this network simulation 


topology. 


public NetInfo(String netName) 
Methods public boolean nodeExists (String name) 
lic void addNode (NodeInfo node) 











lic NodeInfo getNodeByName (String name) 





— lic Hashtable getNodes ( 


Table 5. NetInfo 


a. The nodeExists Method 


This method returns a boolean, true or false, with respect to whether a 
node with the name passed already exists within this topology. 

b. The addNode Method 

This method adds a node to the Net/nfo object by creating a new Nodelnfo 
object with the passed parameters, and then adding this node to the hash table containing 


the nodes of this NetInfo object. 
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CG The getNodes Method 

This method returns a hashtable of nodes of the NetInfo object. 

d. The getNodeByName Method 

This method returns the Nodelnfo object with the name passed in the call. 
5. NodelInfo.java 
The Nodelnfo object contains all the information about a single simulated node 


within the network topology. 


Constructor | public NodeInfo(String nodeName, String nodeType, String 
nodeLoc, String nodeDepth, Channel baseChannel, Hashtable 
secondaryChannels) 


public Channel getBaseChanneli () 





public Hashtable getSecondaryChannels () 
public String getNodeType () 


public String getNodeName () 


u 
u 
u 
pu 
public String getNodeDepth () 
u 


public void setNeighbors (Hashtable n) 





bl 
bl 
bl 
blic String getNodeLoc() 
bl 
bl 
bl 


public Hashtable getNeighbors () 





Table 6. Nodelnfo 


a. The getBaseChannel Method 

This method returns the channel that is the base channel for this node. 
The base channel is used to transmit but is also able to receive. 

b. The getSecondaryChannels Method 

This method returns a hashtable of all the channels of this node in excess 
of the base channel. All of these channels are used to receive. 

G The getNodeType Method 

This method returns the node type as a string and can be stationary or 
mobile. This implementation only uses the stationary type, as mobile nodes are not yet 


implemented. 
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d. The setNeighbors Method 
This method is called by the neighborhoodSetup method of the 
SimControl class, after the neighborhood is built, to update this node’s neighborhood 
hashtable. 
é. The getNeighbors Method 
This method returns the hashtable containing the neighbors of this node. 
6. SAXNetworkInfoParser.java 
This parser uses the XML parser provided by java in the org.xml.sax package and 
implements all methods required by the interface. This implementation is not unique to 
this work and will not be discussed here but can be found in the provided java 
documentation and source code if further study is desired. The endElement method of 
this class will be of interest if studied as it is built to handle the specific attributes of this 
simulation as restricted by the XML DTD provided. If any changes are made to the 
XML DTD, the endElement method will also need to be updated to match. 
Ts SendDelayThread.java 
This class extends the java Thread class and is used to simulate the propagation 
delay in sending packets between nodes. This method is called from the SimControl 
class with the communication thread in which to use, the packet to send and the amount 
of delay in milliseconds. This thread then spawns a thread to sleep for the delay time, 
after which calling the dataToNode method in the specific SimCommsThread to send the 
packet. This simulates the packet arriving a the simulated node at the time in which the 
first bit would have been received in the actual medium. 
D. HELPERS PACKAGE 
The UAN.Helpers package contains classes that do not strictly fit in another 
package. Most of these classes are utilized by many other classes. This package contains 
four classes specifically needed for simulation operation; Address.java, 
Layer2Connect.java, Packet.java, and Payload.java. Also included in this package is a 
ping style class used to test the proper functionality of this simulation, VAN_Ping. java. 
1. Address.java 
This class is used as an object wrapper for an IP and port number to be sent 


through the simulation. This Address object is used by the SimControl class to pass the 


37 


address information of a process requesting access to a simulated node, chosen by the 


controller (SC). 


Constructor | public Address (InetAddress ip, int port) 


Methods lic InetAddress getIP( 





ublic int getPort ( 
Table 7. | Address 





a. The getIP Method 
This method returns the IP address of the process requesting service, as an 
InetAddress. 
b. The getPort Method 
This method returns the port of the process requesting service, as an 
integer. This port is assumed to be a UDP port and is used accordingly by the 
NodeControl and Layer2Connect classes. 
2. Layer2Connect.java 
This class is a helping class for applications to request a connection to the UAN 
Simulation. The requesting application is expected to include, as a minimum, a layer two 
process (functionality). This class is offered as an importable class that is to be 
instantiated by the supported application in order to establish communications with the 
simulation. It is intended to completely abstract the connection implementation and uses 


TCP sockets. The supported application exchanges data with the simulation via the send 


and receive method call of this helping class. 








lic byte[] receive ( 


Table 8. re Interface 
a. The send Interface 


This method call takes a byte array and wraps it in the simulation Payload, 
before passing to the simulation. This provides a common interface for any 
implementation of a layer two process, to use a byte array of data. 

b. The receive Interface 

This method call returns a byte array to the supported process. It unwraps 


the array from the Payload used in the simulation. 
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3. Packet.java 

This class is the wrapper for all information flow within the simulation. A packet 
type can consist of NODEINFO, LAYER2, SIM, or DATA. The DATA type is the only 
packet type that is used during the simulation run. The other types are used for setup and 
debugging. 

Simulation setup requires a destination to be set for packets originating from the 
SimControl class. Since this is not needed during simulation run, it mandated the use of 
two constructors as listed below. The first listed is only used during simulation run, 


while the second listed is used when the SimControl class is forwarding information to a 


specific node. 


public Packet(int type, Payload payload, int channel) 


public Packet (int type, Payload payload, String 
destination, int channel) 





lic void setPayloadSize(int numBytes) 
lic int getPacketType ( 


lic void setSendTime (long time) 











lic long getSendTime ( 





= lic int getPayloadSize ( 


Table 9. Packet 


a. The getChannelID Method 


This method returns the unique channel ID as an integer. 
b. The setSrcName Method 
This method sets the source name of this packet to the name of the node 


that sent this packet to the SimControl class. It is called in the SimCommsThread class. 
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CG. The getSrcName Method 

This method returns a string of the name of the origination node. This 
method is called by the SimControl class. 

d. The getPayload Method 

This method returns the packet payload and is called by classes to unwrap 
packets when needed. 

e. The getPayloadSize Method 

This method returns the size of the payload contained in this packet. It is 
called by the CollisionDetectionThread class and the Layer2ThreadTransmit class. 

f The setPayloadSize Method 

This method sets the packets payload size to the length of the byte array 
passed to the simulation. It is called in the Layer2ThreadTransmit class. 

g. The getPacket Type Method 

This method returns a string, naming the packet type. The options are 
stationary and mobile. Currently only the stationary option is used since mobility is not 
implemented in this version. 

h. The setSendTime Method 

This method sets the transmit time of the packet and is called by the 
Layer2ThreadTransmit class. 

i, The getSendTime Method 

This method returns the transmit time of this packet and is called by the 
SendDelayThread class. 

4. Payload.java 
This class is the wrapper for data passed down from the layer two process. It 

consists of several constructors and method that returns the payload as an object. The 
first constructor is used by the SimControl class to pass the node identity to each 
simulated node. The second constructor is also used by the SimControl class, but to send 
the layer two connection request information to each node. The third constructor is used 


by the Layer2Connect class to wrap the byte array passed from the layer two process. 
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public Payload(NodeInfo node) 
a lic Payload(Address address) 








lic Payload (byte[ 


Method lic Object getData ( 


Table 10. — 











E. NODE PACKAGE 

This package contains all classes needed to perform the functionality of the 
simulated node. These classes include, CollisionDetectionThread, Layer2ThreadReceive, 
Layer2ThreadTransmit, and NodeControl. 

1. CollisionDetectionThread.java 

This class extends the java Thread class and performs the collision detection logic 


of transmitting and receiving messages, per channel, per simulated node. 


public CollisionDetectionThread (boolean base) 


Methods lic void run( 





lic long check(Packet packet, long transRate) 
Table 11. CollisionDetectionThread 





a. The run Method 

This method, as required when extending the java Thread class, handles 
the decision process, based on the current state of the collision detection algorithm. This 
algorithm was defined using a three state FSM in Chapter III. The run method is only 
part of this algorithm. It tests for the expiration of the collision window and then either 
drops the packet or passes it to the upper layer, depending on the current state, which is 
set in the check method. 

b. The check Method 

This method takes the packet passed and determines the time frame of the 
collision window for that packet’s reception. If this is the first packet to arrive, or there is 
no current collision window, then this window becomes the collision window. If there is 
a collision window, then it is determined which window will be open longer. The longer 
window is kept as the collision window and the previous window’s packet is dropped 


since a collision has occurred. If the new packet does not have a longer window, a 
4] 


collision still occurred and the new packet is dropped, keeping the previous collision 
window. The packet associated with the previous collision window, which is also 
considered collided, is dropped once the collision window expires and is accounted for as 


part of the run method described above. 


If this channel is a base channel, the transmission window must also be 
tracked. If there is a transmission window, then it becomes the collision window, the 
same as previously discussed above with determining collision windows. 

2. Layer2ThreadReceive.java 
This class is used as half of an implementation for non-blocking I/O using a TCP 


socket with object streams. This thread is instantiated with the output stream of a socket 


and only passes data from the simulation to the upper layer. 


Constructor public Layer2ThreadReceive (ObjectOutputStream oos) 
Methods public void run() 











public void send(Payload payload) 


Table 12. Layer2ThreadReceive 


a. The run Method 
This method is implemented as required when extending the java Thread 
class and is used only to keep this thread alive. 


b. The send Method 
This method is called by the NodeControl class to pass data to the upper 


layer by writing to the output stream. 

3: Layer2ThreadTransmit.java 

This class is the second half of the non-blocking I/O used with 
Layer2ThreadReceive described above. 


Constructor] public lLayer2ThreadTransmit (ObjectInputStream ois, long 


transRate) 





Table 13. Layer2ThreadTransmit 
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a. The run Method 
This method is implemented as required when extending the java Thread 
class and passes data to the simulation from the upper layer by wrapping the Payload 
received from Layer2Connect with a Packet. It also sets the payload size with a call to 
setPayloadSize, in the Packet class, with the length of the byte array that is the payload. 
It then sleeps for the duration of the transmit window to simulate the reality of only 
transmitting one message at a time, per transmit channel. 
4. NodeControl.java 
This class implements the functionality of the simulated node. The main method 
handles the user I/O and then proceeds into a while-loop to continuously receive data 
from the simulation. When a packet is received, the packet type is checked and the 
proper method is called to handle that packet. During initial setup, the LAYER2 and 
NODEINFO type packets are used. During the simulation run, only the DATA type 
packet is used. An if-else structure is used to check packet type with the DATA 
condition listed first. This ensures that the simulation is not hindered by nested 


statements during the run. 


When a DATA type packet is received, the collisionDetection method is called. 

When a LAYER? type packet is received, the connectLayer2 method is called. When a 
NODEINFO type _ packet’ is received, the buildNode and __ then 
startCollisionDetectionThreads methods are called. 

a. The collisionDetection Method 

This method determines the correct collision detection thread for which to 
send the packet, based on the ID of the channel on which this packet was transmitted. 
The check method of this thread is then called with this packet. 

b. The startCollisionDetection Threads Method 

This method is part of setup and is called after the buildNode method has 
been completed. It starts a collisionDetectionThread for each channel of this node. 

CG. The buildNode Method 

This method is part of setup and builds this node with the information sent 


to it from the SimControl class. 
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d. The getChannelRate Method 

This method is called when the transmission rate of a channel is needed. 
Given the unique channel ID, this method returns the transmission rate. 

e. The connectLayer2 Method 

This method is part of setup and makes the connection to the layer two 
process. After receiving the Address from the SimControl class, it creates a TCP server 
socket and UDP socket on the same port number. It then sends an empty UDP packet 
from this port, to the Address received. This allows the other side to pull the IP and port 
number from the UDP packet and use that as the listening port. This “other side” is the 
Layer2Connect class that the layer two process instantiated as a helper function. Once a 
connection is established, a Layer2ThreadReceive thread and a Layer2ThreadTransmit 
thread are created with an object output stream and object input stream, respectively. 

a: The receiveData Method 

This method receives data from the simulation and calls the send method 
of the Layer2ThreadReceive class to pass to the upper layer. This method is 
synchronized to ensure only one collision detection thread can pass data at a time. 

g. The transmitData Method 

This method is called by the Layer2ThreadTransmit class and then writes 
to the output stream to send data into the simulation. 


EF. DIRECTION 


This chapter has laid out the details, reasons for, the implement of this work. The 
next chapter will wrap everything up with an overview of the big picture and tool 
capabilities. It will also define future work options and specific hooks already in place to 


facilitate specific future works. 
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V. CONCLUSIONS AND FUTURE WORK 


A. CONCLUSIONS 

The goal of this thesis was to provide a more hospitable, adaptable, flexible, and 
easily useable environment in which to test protocols for UANs, as well as providing the 
ability for the Physics field to test new physical layer devices. This simulation 
environment was to also provide the glue, or bridge, between the two disciplines by 


working as a common tool for both. 


This thesis met these goals by implementing a simulation tool that provides 
message distribution between simulated UAN entities, low simulation overhead and 
proper representation of acoustic characteristics of the medium as enhanced by 
characteristics of the physical device used to transmit and receive. This tool provides 
significant flexibility for modeling various protocols representing different layers of the 
UAN functionality. A key aspect of the model is its focus on reuse, where different 
protocol implementations or modeling techniques can be instantiated by the user of this 
work, in order to demonstrate or evaluate the performance of the protocols or techniques 
of interest without modification to the underlying message exchange mechanism. The 
only requirement of this underlying mechanism is that data is exchanged via a byte array. 
This is a reasonable requirement as all programming languages, which might be used 


with this simulation tool, can handle byte arrays in some form. 


This thesis work, in time-base simulations, provides the tool long need for testing 
high latency protocols required to facilitate underwater acoustic networking. Even 
though this work does not specifically provide for physical device (modem) testing, it is 
modularized with forethought to this ability and is ready for implementation in the next 


version. It is protocol testing where this work is ready for immediate application and use. 


With the designed ability to run on a single computer or a network of computers, 
this thesis provides a tool that is scalable for almost all protocol testing needs from the 


simplest network topology, to the very complex. Once a topology is defined with a XML 
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document, the user is assured that each protocol tested, is running with the same network 
conditions with respect to topology. This specifically allows for affective comparison 


testing of many different protocols. 


The minimizing of simulation overhead was kept to less than 100 milliseconds per 
RTT. The actual number appears to be closer to 90 milliseconds but enough runs of 
identical topologies were not completed to evaluate an average and standard deviation 
that could be reliably subtracted within the simulation. Simulation runs were only 
performed with intent to validate functionality of the simulation tool itself. The overhead 
was kept to a minimum by minimizing the busy-wait conditions encountered when using 
an infinite while-loop. In all cases where a while-loop is used, only one iteration of a 
loop is needed before a decision is made within this thread or that another thread needs to 
make a decision based on this thread. To force this utilization, each process using a 
while-loop is forced to yield at the end of each loop’s iteration. This was able to lower 
simulation overhead by more than 200 milliseconds per RTT. 
B. FUTURE WORK 

This thesis restricted itself to stationary nodes, but a possible future work is to 
implement the mobile node. This would require dynamic topology updates to be able to 
be sent to each node, which would require changes to, at minimum, the NodeControl and 
SimControl classes. This ability would greatly increase this tool’s value as the ability to 


simulate UUVs and mobile sensors. 


This thesis implemented a static acoustic propagation model. Future work is 
desired in implementing one of the more complex acoustic models, possibly with the use 
of a server farm, in order to provide a more dynamic representation of the medium. This 


would also provide for a more realistic simulation environment in which to test protocols. 


This thesis work only allows for topologies to be loaded via a pre-formed XML 
document. A future work might be implementing a GUI that allows for build a topology 


from a visual aspect. 


This thesis work was restricted to testing protocols, but with forethought of 
testing physical modem devices also. This interface does not currently exist. This 


interface would act as a middleware device between the physical modem and the 
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simulation. This would benefit this work by allowing for physical device testing at the 


same time with protocols and vice versa. 


One other possible future work would be the idea multiple remote UAN agents. 
That is, a given network may be allocated for part-time use of the UAN simulation and 
would have a UAN service agent running in the back ground. When a user wants to start 
a simulation, the Simulation Control agent would then contact and utilize as many 
waiting node agents a needed for the simulation. This could be accomplished via RPC, 
RMI or some interface written specifically for the UAN simulation. This would benefit 
the user greatly in setup and utilization time and possibly the ability to run more than one 


simulation from the same Simulation Contro ler. 
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APPENDIX A: SOURCE CODE 


UAN.SIM PACKAGE 
1. SimControl.java 
package UAN.Sim; 


import UAN.Channels. Channel; 

import UAN. Helpers. Address; 

import UAN. Helpers. Packet; 

import UAN. Helpers. Payload; 

import UAN. Node. NodeControl; 

import java.io.* 

import javax.net.*; 

import java.net.*; 

import java.util. *; 

import java. lang.*; 

import javax.swing. JFileChooser; 

import javax.swing. JFrame; 

/** 
* SimControl is the central point of control and logic for this test-bed 
* environment and must be the first to run. 


* Tt maintains all socket connections to all clients and employs all the logic 


* for the centralized model view. 


* Tt also reads network topology from an XML file and then stores this ina 


* <code>NetInfo</code> object. 
zi 
public class SimControl 


{ 


/*#* 
* Used as channel ID if packet is administrative. 
#h 
final static int DCID = 99; 
/*#* 
* This TCP port will listen for connections from remote nodes. 
*) 
final static int ADMIN PORT = 2875; 
/#* 
* This TCP port will listen for connections from remote applications 
* that wish to connect and act as a layer 2 protocol. 
*/ 
final static int LAYER2 REQUEST PORT =3282; 
/** 
* Defines the TCP Server Socket buffer size for listening. 
*/ 
final static int BACK_LOG = 100; //buffer for accepting connections 
/** 
* Defines the maximum distance (time in milliseconds) of realistic 
* communications based on current abilities of 1000 meters and the 
* average speed of sound through water of 1500 meters per second. 
*/ 
final static int LINK LOSS THRESHOLD = 667; //milliseconds 


[e* 
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* This hashtable is used as a point for reference to all threads that are 
* spawned for communications between <code>SimControl</code> and the 
* remote nodes. 
#/ 
static Hashtable threadList |= new Hashtable(); 
/*#* 
* This holds all the information about the network topology read from 
* the XML file. 
*/ 
static NetInfo myNet = null; 


//77® VLAN 20H e Ra RGR IIS SIGCSE III ICICI CCI 
[PER BERS ISIS SCSI CCIGIGCICICCIGIC CICS ICICI CII 
/** 
* Main contains only the major logic calls. 
* @param args Standard args for Main 
*/ 
public static void main(String[] args) 
{ 
readTopology(); 
neighborhoodSetup(); 
makeNodeConnections(); 
deployNodes(); 
listen4layer2(); 
}//end main 


/72 7 Body Methods (0b C RCH GHG BBC EEE BSCE CEE ECR R IRR IE IE 


[** 
* Parses the XML file into a <code>NetInfo</code> object 
*) 
private static void readTopology() 
{ 
SAXNetworkInfoParser parser = new SAXNetworkInfoP ars er(); 
myNet = parser. parse(chooseFile()); 
}//end readTopology 
[e* 
* Build the neighborhoods. 
4 
private static void neighborhoodSetup() 


int delay = 0; 
Enumeration enumOuterLoop = myNet. getNodes(). elements(); 
while(enumOuterLoop. hasMoreElem ents()) 
{ 
Hashtable neighbors = new Hashtable(); 
NodelInfo outerLoopNode = (Nodelnfo ) enumOuterLoop.nextElem ent(); 
Enumeration enumInnerLoop = myNet.getNodes().elements(); 
while(enumInnerLoop.hasMoreElements()) 
{ 
NodelInfo innerLoopNode = (NodelInfo ) enumInnerLoop.nextElement(); 
if(!outerLoopNode. getNodeName(). equals(inn erLoopNode. getNodeN ame())) 


delay = calcLoss(outerLoopNode, innerLoopNode); 
if( delay < LINK LOSS THRESHOLD) 
{ 
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neighbors. put(innerLoopNode. getNodeNam e(), 
new NeighborInfo(innerLoopNode, delay)); 


System. out.println("Node: "+ 
outerLoopNode. getNodeNam e() + 
"Node: "+ innerLoopNode. getNodeN ame() + 
" are neighbors with delay: "+delay); 
}//end if less than threshold 
}/end if not myself 
}//end while inner loop 
outerLoopNode.setNeighbors(neighbors ); 
}//end while outer loop 
}//end neighborhoodS etup 
/ KK 
* Spawns a new thread for each node to handle all communications between 
* nodes <code>NodeControl</code> and <code>SimControl</code>. 
* Populates a hashtable with these threads so <code>SimControl</code> 
* can access in the logic section. 
*/ 
private static void makeNodeC onnections() 
{ 
NodelInfo thisNode; 
String thisNodeName; 
ServerSocket listenSocket = null; 
Socket socket = null; 
SimComms Thread thisThread; 
Enumeration enumNodes; 
try { 
listenSocket = new ServerSocket(ADMIN_ PORT, BACK LOG); 
} catch IOException ex) { 
ex. printS tackTrace(); 
System. out. println("Could not create a ServerSocket" ); 


} 


System.out printIn("Sim Control waiting for connections"); 
enumNodes = myNet. getNodes().elements(); 
while(enumNodes.hasMoreElements()) //make a connection for each node 


thisNode = (NodeInfo) enumNodes.nextElement(); 
thisNodeName = thisNode. getNodeName(); 
try { 
socket = listenSocket.accept(); 
socket.setKeepAlive(true); 
} catch IOException ex) { 
ex. printS tackTrace(); 
System.out.println("Could not create a new Socket"); 
} 
System.out println("DS IP is: "+ 
socket. getLocalAddress(). toS tring()); 
thisThread = new SimCommsThread(socket, thisNodeName); 
threadList.put(thisNodeName, thisThread); 
thisThread. start(); 
thisThread. setName(thisNodeNam e); 
}//end while more nodes 
System.out.println("no more nodes to connect to"); 
}//end makeNodeC onnections 
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/ KK 
* Sends the node info to each node. This asigns each remote node 
* connection with the physical properties of one of the nodes described 
* in the topology. 
*/ 
private static void deployNodes() 
{ 
Enumeration enumNodes = myNet. getNodes().elements(); 
NodelInfo thisNode; 
Packet newPacket; 
while(enumNodes.hasMoreElements()) 


thisNode = (NodelInfo) enumNodes.nextElement(); 
newPacket = new Packet(Packet. NODEINFO, 

new Payload(thisNode), thisNode. getNodeName(), DCID); 
forwardP ack et(newPacket); 


} 
}//end deployNodes 
/*#* 
* Receives an empty datagram from an application requesting to connect as 
* a layer 2 protocol and then passes this packet's IP and port number to 
* the next available node in the form of an <code>Address</code> object. 
3} 
private static void listen4layer2() 
{ 
DatagramSocket dgSkt = null; 
DatagramPacket dgPkt = null; 
int port; 
Enumeration enumNodes; 
NodelInfo thisNode; 
try { 
dgSkt = new DatagramSocket(LA YER2 REQUEST PORT); 
} catch (SocketException ex) { 
ex. printS tackTrac e(); 
System.out printIn("Could not create a new DatagramSocket in listen4Layer2"); 
} 
dgPkt = new DatagramPacket (new byte[0], 0); 
enumNodes = myNet.getNodes().elements(); 
while(enumNodes.hasMoreElements()) //more nodes to connect layer2 


thisNode = (NodelInfo) enumNodes.nextElement(); 
try { 
dgSkt. receive(dgPkt); 
} catch IOException ex) { 
ex. printS tackTrace(); 
System. out printIn("Problem with receiving datagram packet in listen4Layer2"); 


he ack et(new Pack et(Pack et. LAYER2, 
new Payload( 
new Address(dgPkt. getAddress(),dgPkt. getPort())), 
thisNode. getNodeName(), DCID)); 
}//end while 
}/end listen4layer2 


77° Helper Methods (eH GHG GGG E BR SEAR ECE IE ESS B CRI RIG SICA I RICK III / 
[e* 
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* GUI file chooser for selecting the XML file to load the topology from. 
* @retum a <code>File</code> choosen to parse. 
e) 
private static File chooseFile() 
{ 
File file = null; 
JFileChooser fileChooser = new JFileChooser(); 
fileChooser. setF ileS electionMode(JFileChooser. FILES AND DIRECTORIES); 
int result = fileChooser.showOpenDialog(new JFrame()); 
if (result == JFileChooser. APPROVE OPTION) 


{ 
file= fileChooser. getS electedFileQ); 
return file; 
} 
return null; 
}//end chooseFile 
[ee 
* Sends this packet to the node. 
* @param p the <code>Packet</code> being sent. 
*) 


static void nodeData(Packet p) 
{ 
sendToNeighborhood(p); 
}//end nodeData 
[ee 
* Emulates the broadcast environment by sending to all of the 
* originating node's neighbors. 
* @param p the <code>Packet</code> being sent. 
#/ 
private static void sendToNeighborhood(Pack et p) 


Hashtable thisNeighborhood = myNet.getNodeByName(p. getSrcName()). getN eighbors(); 
Enumeration enumNeighbors = thisNeighborhood.elements(); 
SimCommsThread thisThread = null; 
SendDelayThread pdThread = null; 
Nodelnfo nodelInfo = null; 
NeighborInfo neighborInfo = null; 
int delay = 0; 
while(enumNeighbors.hasMoreElements()) 
{ 
neighborInfo = (NeighborInfo) enumNeighbors.nextElem ent(); 
nodelInfo = neighborInfo. getNode(); 
delay = neighborInfo. getDelay(); 
thisThread = (SimCommsThread) threadList. get(nodeln fo. getNodeN ame()); 
pdThread = new SendDelayThread (thisThread, p, delay); 
pdThread. start(); 


} 
}//end sendTodNeighborhood 
/** 
* Sends a received packet to the destination node. 
* Used only for configuration and admin. These packets originated 
* at the sim control. 
* Called by <code>deployNodes</code> 
* @param p the <code>Packet</code> being sent 
#) 
private static void forwardP ack et(Pack et p) 
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SimCommsThread thisThread; 
thisThread = (SimCommsThread) threadList. get(p. getDestNam e()); 
thisThread.dataToNod e(p); 
}//end forwardP ack et 
/[** 
* Calculates the loss between nodes based on the distance between 
* nodes return an integer representing the propogation delay between them. 
* @param a any given node 
* @param b any other node to check against 
* @return an <code>Integer</code> representing the propogation delay in milliseconds 
*/ 
private static int calcLoss(Nodeln fo a, NodelInfo b) 
{ 
int delay = 0; //milliseconds 
String[] LocA = a.getNodeLoc().split(" "); 
String[] LocB = b.getNodeLoc().split(" "); 
double LatA = Double. parseDouble(LocA [0]); 
double LonA = Double. parseDouble(LocA [1]); 
double LatB = Double. parseDouble(Lo cB [0]); 
double LonB = Double. parseDouble(LocB [1 ]); 
double dist = distance(LatA, LonA, LatB, LonB); 
System. out. println("Node pair "+a. getNodeName()+"::"+ 
b.getNodeName()+" has distance: "+dist+" meters"); 
//will check if loss of precision makes a difference 
//may change to nanoseconds later 
delay = (int)(dist / 1.5); 
//1.5 comes from dividing by 1500 m/s and multipling by 1000 to get milliseconds 
return delay; 
}//end calcLoss 
[e* 
* Calculates distance in meters between two points given as latitude and 
* longitude in decimal degree format. 
* @param lat! the latitude of the first node 
* @param lon! the longitude of the first node 
* @param lat2 the latitude of the second node 
* @param lon2 the longitude of the second node 
* @retum a <code>double</code> representation of the distance between nodes in meters. 
4 
private static double distance(double lat1, double lon1, double lat2, double lon2) 


double theta = lon! - lon2; 

double dist = Math. sin(Math.toRadians(lat1)) * Math.sin(Math.toRadians(lat2)) + 
Math. cos(Math. toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * 
Math. cos(Math. toR adians(theta)); 

dist = Math.toDegrees (Math. acos(dist)); 

dist = dist * 60; //nautical miles 

dist = dist * 1852; //meters 

return dist; 

}//end distance 


[** Testing Methods #22 298 9 924 9594 958 2 5 I EE CI EE EI RE ER EC AE EK / 
[ee 
* Testing method to display nodes and modems of the the whole 
* topology. 
* @param net the whole network topology. 
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*/ 
private static void display(NetInfo net) 
{ 
Enumeration eNode = net. getNodes().elements(); 
while(eNode. hasMoreElem ents()) 
{ 
NodelInfo n = (NodeInfo) eNode.nextElement(); 
System. out. println("Node: "+ n.getNodeName()); 
Enumeration eChannels = n.getSecondaryChannels(). elem ents(); 
while(eChannels. hasMoreElements()) 


Channel m = (Channel) eChannels.nextElement(); 
System. out printIn("Channel: "+ m.getName()); 


} 


} 

}//end display 
[e* 

* Testing method 

* Receives packet object from a node and then sends to other node(s) based 
* on destination. 

* @param p the packet to send. 

*/ 
public static void nodeDatal (Pack et p) 


{ 
if(p. getDestName(). equalsIgno reCas e(Nod eControl. BROADCAST _ID)) 
{ 


broadcastNodes(p ); 
} 


else 
forwardP ack et(p); 


}//end nodeDatal 
/** 
* Sends a received packet to all nodes when the destination ID was set to 
* Broadcast. 
* This is a testing method only and does not limit sending to a 
* neighborhood. 
* @param p the <code>Packet</code> 
*/ 
private static void broadcastNodes(Packet p) 
{ 
SimComms Thread thisThread; 
Enumeration thList = threadList.elements(); 
while(thList. hasMoreElements()) 


thisThread = (SimCommsThread) thList.nextElement(); 
thisThread.dataToNod e(p); 
}//end while 
}//end broadcastNodes 
[e* 
* testing method call to distance 
*) 
private static void calcDistance() 


{ 
System. out. println(distance(32, -96, 32, -96.02) +" Meters\n"); 
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}//end calcDistance 
}//end SimStaion 


2. SimCommsThread.java 
package UAN.Sim; 


import UAN. Helpers. Packet; 
import UAN. Helpers. Payload; 
import java.io. *; 
import java.net.*; 
import java. lang.*; 
/*%* 
* <code>SimCommsThread</code> extends <code>Thread</code> and handles 
* all communication between <code>SimControk/code> and each node. 
* A seperate thread is used to communicate to each instance of 
* <code>NodeControl</code> running in the simulation. 
=) 
public class SimCommsThread extends Thread 
{ 
private Socket skt = null; 
private ObjectOutputStream oos; 
private ObjectInputStream ois; 
/*#* 
* Constuctor 
* @param socket the <code>Socket</code> that this thread manages. 
* @param name the <code>String</code> that represents this thread's name. 
of 
public SimCommsThread(Socket socket, String name) 


super(name); 
skt = socket; 
}//end constructor 
/** 
* Thread implementation of run. 
*/ 
public void run() 
{ 
try 
{ 
oos = new ObjectOutputStream(skt. getOutputS tream()); 
ois = new ObjectInputStream(skt. getInputS tream()); 
Payload s; 
Packet p; 
while(true) 


p= (Packet) ois.readObject(); 
dataToSim(p); 
yield(); //minimizing busy wait 


j 
} catch (IOException ex) { 
ex. printS tackTrac e(); 
} catch (ClassNotFoundException ex) { 
ex. printS tackTrace(); 
}//end trycatch 
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}//end run 
[** 

* Sends a packet from <code>SimControl</code> to node via the 
* output stream. 

* 

* @param p the <code>Packet</code> being sent. 

*/ 
public void dataToNode(Packet p) 

{ 

try 


oos. writeObject(p); 
oos. flushQ); 


} catch IOException ex) { 
ex. printStackTrace(); 
System. out. println("Could not write to Output Stream in dataToNode"); 


} 
}//end dataToNode 
[e* 
* A <code>Packet</code> was received from a node in <code>run</code> 
* and is sent to <code>SimControl</code>. 
* Synchronized to ensure only one thread is passing data to 


* <code>SimControl</code> at a time. 
* 


* @param p the <code>Packet</code> being sent. 
#/ 
private synchronized void dataToSim(Packet p) 


if(p.getPacketType(Q) == Packet.SIM) 


SimControl. nodeDatal (p); 
} 


else 


p.setSrcName(this. getName()); 
SimControl. nodeData(p); 


} 
}//end dataToSim 
}//end SimCommsThread 


3: NeighborInfo.java 
package UAN.Sim; 


import java.io.Serializable; 

[e* 

* Holds the different delay costs for the same node wrt different 

* neighborhoods. This is also the place later to store the loss data from 
* the server farm about the acoustic channel. This supports bidirectional 
* differences in transmission characteristics. 
*/ 

public class NeighborInfo implements Serializable 


{ 


[re 
* Holds the node information 
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*) 
private NodeInfo nodelnfo; 
[e* 
* Holds the delay in milliseconds 
*/ 
private int delay; 
[e* 
* Constructor 
* @param node the <code>Nodelnfo</code> 
* @param num this node's propogation delay relative to the node that this 
* node a neighbor of. 
*“ 
public NeighborInfo(Nodeln fo node, int delay) 
{ 
nodelnfo =node; 
this.delay = delay; 


[e* 
* Use this method to get the Node 
* @retum <code>Nodelnfo</code> 
*/ 

public NodeInfo getNode() 


retum nodelInfo; 


[e* 


* Use this method to get the delay time 
* @retur <code>Integer</code> representing delay time 
*/ 

public int getDelay() 


return delay; 


} 


}//end NeighborNode 


4. NetInfo.java 
package UAN.Sim; 


import UAN.Channels. Channel; 

import UAN.Sim.Nodelnfo; 

import java.util. *; 

/** 

* A record of information that describes a network. 
ef 

public class NetInfo 

{ 


[e* 
* This network's name. 
*/ 
private String netName; 
[** 


* Hashtable to store node info of this topology. 
*/ 
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private Hashtable nodeTable = new Hashtable();//store all the nodes in this net 
[re 

* Set the network name. 

* @param netName a <code>String</code> of the network name. 

me 
public NetInfo(String netName) 

{ 


this.netName = netName; 


/ ok 
* Checks whether the node already exists on the network. 
* @param name the <code>String</code> of the node name. 
* @returm <code>boolean</code> representing whether the node already exists. 
4 
public boolean nodeExists(String name) 


t 
if (nodeTable. get(name) == null) 
{ 


return false; 
} 
return true; 
} //end of nodeExists() 
/ 2K 
* Adds a node to this NetInfo object. 
* @param nodeName a <code>String</code> of node name. 
* @param nodeType a <code>String</code> of node type. 
* @param nodeLoc a <code>String</code> of node location. 
* @param nodeDepth a <code>String</code> of node depth. 
* @param baseChannel a <code>Channel</code> for node base channel. 
* @param secondaryChannelTable a <code>Hashtable</code> of secondary channels. 
* @retum the new node as <code>NodelInfo</code> 
*/ 
public NodeInfo addNode(String nodeName, 
String nodeType, 
String nodeLoc, 
String nodeDepth, 
Channel baseChannel, 
Hashtable secondaryChann elTable) 
{ 
NodeInfo newNode = new Nodelnfo( nodeName, 
nodeType, 
nodeLoc, 
nodeDepth, 
baseChannel, 
secondaryChann elTable); 


//add NodelInfo object to hash table 
nodeTable.put(nodeName, newNode); 


return newNode; 
} //end of addNode() 
[** 
* Node table of this NetInfo object. 
* @retum Table of nodes as <code>Hashtable</code> 
*/ 
public Hashtable getNodes() 
{ 
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return nodeTable; 


} 


[re 
* Returns the node belonging to the network, and whose name matches 
* with the given name. If no nodecan be found, a null is returned. 
* @param name the <code>String</code> of node name. 
* @returm <code>Nodelnfo</code> of the node name. 
*/ 
public NodeInfo getNodeByN ame(String name) 


{ 
return (NodeInfo) nodeT able. get(n ame); 


} 
}//end of class NetInfo 


5. NodelInfo.java 
package UAN.Sim; 


import UAN.Channels.*; 
import java.io.Serializable; 
import java.net. InetAddress; 
import java.util. *; 


[e* 

* Holds the information about a given node in the topology. Is serializable so 
* that it can be sent as an object over input and output streams. 

*/ 

public class NodeInfo implements Serializable 


{ 


/** 
* A <code>String</code> for this node's name. 
*/ 

private String nodeName; 

/*%* 
* A <code>String</code> for this node's type. 
*/ 

private String nodeType; 

/** 
* A <code>String</code> for this node's location. 
*/ 

private String nodeLoc; 

/*%* 
* A <code>String</code> for this node's depth in lat/long, decimal degree format. 
oh 

private String nodeDepth; 

/*%* 
* An <code>InetAddress</code> for the physical on which this node resides. 
*/ 

private InetAddress hostIPv4; 

/** 
* A <code>short</code> to represent the TCP port. 
*/ 

private short tepPortNumber; 

/** 
* Base channel will always transmit 
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* 

ve Channel baseChannel; 

2K 

_ A <code> ArrayList</code> of channels. 
* 

ceo Hashtable secondaryChann els; 

2K 

= A <code>Hashtable</code> of neighbors. 
* 

sae Hashtable neighbors; 


/*%* 
* Constructs a NodelInfo object. 
* @param nodeName the <code>String</code> of the node name. 
* @param nodeType the <code>String</code> of the node type. 
* @param nodeLoc the <code>String</code> of the node location. 
* @param nodeDepth the <code>String</code> ofthe node depth. 
* @param baseChannel the <code>Channel</code> that is the base channel. It can transmit 


and receive. 
* @param secondaryChannels a <code>Hashtable</code> of other channels of this node. 


*/ 
public NodeInfo(String nodeName, 
String nodeType, 
String nodeLoc, 
String nodeDepth, 


Channel baseChannel, 
Hashtable secondaryChann els) 


this. nodeName = nodeName; 
this. nodeType = nodeType; 
this. nodeLoc = nodeLoc; 
this. nodeDepth = nodeDepth; 
this.baseChannel = baseChannel; 
this.secondaryChannels = secondaryChannels; 
} //end of constructor 
/ 2K 
* Returns the base channel of this node 
* @retum Channel 
4 
public Channel getBaseChannel() 
{ 


return baseChannel; 


/[** 

* Returns the secondary channel hashtable of this Node. 
* @returm <code>Hashtable</code> 

*/ 

public Hashtable getS econdaryCh annels() 

{ 


return secondaryChannels; 


/[** 
* Returns the node type of this NodelInfo object. 
* @return <code>String</code> for Node type 
*/ 

public String getNodeType() 
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{ 


return nodeType; 


[re 

* Returns the node name of this NodeInfo object. 

* @returm Name of the node as a <code>String</code>. 
ay 

public String getNodeName() 

{ 


return nodeName; 


[e* 


* Gets this node's location 

* @retum this node's location as a<code>String</code> 
*) 

public String getNodeLoc() 

{ 


return nodeLoc; 


[e* 


* Retums the water depth of this node 
* @retum the water depth of this node 
*/ 

public String getNodeDepth() 

{ 


return nodeDepth; 


[e* 


* Set the neighborhood for this node. 

* @param n the <code>Hashtable</code> of neighbors. 
*) 

public void setNeighbors(Hashtable n) 

{ 


neighbors = n; 


[e* 


* Returns the neighborhood. 

* @retum <code>Hashtable</code> of neighbors. 
*/ 

public Hashtable getNeighbors() 

{ 


retum neighbors; 


} 
}//end of class NodeInfo 


6. SAXNetworkInfoParser.java 
package UAN.Sim; 


import java.io. * 
import java.net.*; 


import java.util. *; 


import UAN.Channels.*; 
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//XML-SAX parser imports 
import org.xml.sax. Attributes; 
import org.xml.sax.ContentHandler; 
import org.xml.sax. ErrorHandler; 
import org.xml.sax. Locator; 
import org.xml.sax.SAXException; 
import org.xml.sax.SAXParseException; 
import org.xml.sax.XMLReader; 
import org.xml.sax. helpers. XMLReaderF actory; 
/ 78K 
* Parses an XML file using SAX parser to load the network information of the 
* <code>SimControlk/code>. 
auf 
public class SAXNetworkInfoP ars er 


NetInfo myNet = new NetInfo("U AN"); 


[e* 
* Default constructor 
* 

public SAXNetworkInfoPars er() 


{ 
//empty 


[e* 


* Parses an XML file using the SAX parser. 
* 


* @param file Input XML file 
* @retum <code>NetInfo</code> containing the newly parsed information. 
*) 

public NetInfo parse (File file) 


{ 
URL url= null; 
try 


url = filetoURLOQ; 


catch (MalformedURLException e) 

{ 
System.out.println("Cannot load file. Malformed URL: "+ e.getMessage()); 
return null; 


ContentHandler contentHandl er = new UANTopologyContentHandler(); 
ErrorHandler errorHandler = new MyErrorHandler(); 
try 


esata aSAX parser 

XMLReader parser 
XMLReaderF actory.createXMLRead er("org.apache. xerces. pars ers.S AXParser" ); 

//Register the content handler 

parser. setC ontentHandler(contentHandl er); 

//Register the error handler 

parser.setErrorH andler(errorH andler); 

//Parse the document 

parser. parse(url.toString()); 


} 
catch (IOException ie) 
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System.out.println("Cannot load file. Error reading URL: " + ie. getMessage()); 
i 
catch (SAXException se) 


System.out printIn("Error in parsing: "+ se getMessage()); 
se. printS tackTrace(System. err); 
} 
return myNet; 
} //end of parse() 
/** 
* Inner class <code>UANTopologyC ontentHandler</code> implements the SAX 
* interface and parses the document based on the events that happen inside 
* the document. It establishes the basic data structures that gather the 
* network topology information from the XML file. 
*/ 
class UANTopologyContentHandler implements ContentHandler 
{ 
//Hold onto the locator for location information 
private Locator locator; 
private Channel newChannel = null; 
private Channel baseChannel = null; 
private boolean BASE SET = false; 


//global & temp variables to store values read from the XML file 
String element = '""; 

String value She 

String hostIPv4  =""; 

String nodeName = ""; 

String nodeType =""; 

String nodeLocation = ""; 

String nodeDepth = ""; 

String channelName = ""; 

String channelID = ""; 


NodelInfo newNode; 


Hashtable secChannelTable; 
[e* 
* This method gives the capability to define the exact location while 
* parsing the XML file. 
* @param locator Document locator 
*/ 
public void setDocumentLocator(Lo cator locator) 


System.out.println(" * setDocumentLocator() called"); 
//We save this for later use if desired. 
this. locator = locator; 


/#* 
* In this method there can be any kind of statements that we would like 
* to occur when we first open an XML document. 
* @throws SAXException when thins go wrong 
*/ 
public void startDocument() throws SAXException 


{ 
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System.out.println("Parsing begins..."); 


[e* 
* This reports the occurrence of an actual element. It will include the 
* element's attributes, with the exception of XML vocabulary specific 
* attributes like "DTD", ... 
* @param namespaceURI Namespace URI 
* @param localName Local name 
* @param rawName Raw name 
* @param atts Attributes 
* @throws SAXException when things go wrong 
*) 
public void startElement(String namespace URI, 
String localName, String rawName, Attributes atts) 
throws SAXException 
{ 
System.out. printIn(" startElement: OK right here. "+ localName); 
element = localName; 


/*#* 

* Returns the real value stored in the XML element and then converted 
* toa string " array of characters ". 

* @param ch Characters 

* @param start Start position 

* @param end End position 

* @throws SAXException when things go wrong 

*/ 
public void characters (char [] ch, int start, int end) throws SAXException 
{ 

String s = new String(ch, start, end); 

value = s; 


} 


[e* 
* Indicates the end of an element is reached. Note that the parser does 
* not distinguish between empty elements and non-empty elements, so this 
* will occur uniformly. We gather the value of the element when we reach 
* the end of the element. 
* @param namespaceURI Namespace URI 
* @param localName Local name 
* @param rawName Raw name 
* @throws SAXException when things go wrong 
*/ 
public void endElement(String namespaceURI, 
String localName, String rawName) throws SAXException 


“ (localName.equals("UAN_Net")) 
System.out printIn("This completes a UAN network!!"); 

a if (localName. equals("Node")) 
System. out println("=—==—=—==—=— End of a new node === == ====="); 
//Check if node already exist. If it indeed exists already, warn user 


if (myNet.nodeExists(nodeName)) 


System. out println("Node already exists: " + nodeName + 
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"node not added to the network"); 
retum; 


//Check if node has any channel. Ifit doesn't, warn user 
if (baseChannel == null) 
{ 
System. out println("Node does not have any channel: "+ nodeName + 
"node not added to the network"); 
return; 
} 
newNode = myNet.addNode( nodeName, 
nodeType, 
nodeLocation, 
nodeDepth, 
baseChannel, 
secChannelTable); 


} 
else if (localName. equals(""NodeType")) 


nodeType = value; 
System.out println(" Node Type = "+ nodeType); 


else if (localName. equals("NodeLocation")) 


t 
nodeLocation = value; 
System.out println(" Node Location = "+ nodeLocation); 


} 
else if (localName. equals("NodeDepth")) 


nodeDepth = value; 
System.out println(" Node Depth = "+ nodeDepth); 


else if (localName. equals(""Node Name" )) 
{ 


nodeName = value; 

System. out println("===——=—=— Start of a new node === = =—==="); 
System.out.println(" Node Name =" + nodeName); 

BASE SET = false; 


//This is the beginning of anew node, initialize the following variables 
secChannelTable = new Hashtable(); 


else if (localName. equals("Channel")) 


{ 
System. out. println("=—==——==—=—= End of New Channel =========="); 


else if (localName. equals("ChannelN ame") ) 


{ 
channelName = value; 
System.out println(" Channel Name = "+ channelName); 


} 
else if (localName. equals("ChannelID")) 


channelID = value; 
System.out.println(" Channel Type = "+ channelID); 
//Create a new channel record. Since the node object has not been 
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//created yet, we use null as the parent node for now. The parent node will 
//be set once the node information has been parsed completely. 
if(channelID. equals("0")) 


newChannel = new ChannelZero(channelName); 
System.out printIn("This is aChannel Zero"); 


} 
else if(channelID. equals("1" )) 


newChannel = new ChannelOne(channelN ame); 
System.out printIn("This is a Channel One"); 

} 

else if(channelID. equals("2" )) 

{ 
newChannel = new ChannelTwo(channelName); 
System.out printIn("This is aChannel Two"); 


} 
if((/BASE_SET) 


baseChannel = newChannel; 
BASE SET = true; 
System. out println("Base Channel set as "+ baseChannel.getName()); 


} 


else 


secChannelTable. put(channelName, newChann el); 


} 


} 
} //end of endElement() 
/*#* 
* Indicates the end of the XML document. It is reached when it finishes 
* all the parsing events inside that we would like to occur when we first 
* open an XML document. 
* @throws SAXException when things go wrong 
*/ 
public void endDocument() throws SAXException 
{ 
System.out.println("...Parsing ends."); 
} // end of endDocument() 
/#* 
* This method is used when processing instructions (PI) are found in 
* the XML file. The current XML file doesn't support PI. 
* @param target 
* @param data 
* @throws SAXException when things go wrong 
#/ 
public void processingInstruction (String target, 
String data) throws SAXException 


System.out.println("PI: Target: " + target + " and Data: " + data); 


[e* 
* This method is used in case XML name spaces are used. 
* Tn the current use of XML, name spaces are not supported. 
* @param prefix 
* @param uri 
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*/ 
public void startPrefixMapping (String prefix, String url) 


System.out printIn("Mapping starts for prefix "+ 
prefix + "mapped to URI "+ uri); 
} 


[e* 
* This method is used in case XML name spaces are used. 
* Tn the current use of XML, name spaces are not supported. 
* @param prefix 
*/ 
public void endPrefixMapping (String prefix) 


System.out.printIn("Mappine ends for prefix " + prefix); 


/** 
* This method provides the ability to report white spaces. 
* @param ch Character array 
* @param start Start position 
* @param end End position 
* @throws SAXException when things go wrong 
*/ 
public void ignorableWhitespace (char [] ch, int start, int end) 
throws SAXException 
{ 
String s = new String(ch, start, end); 
System. out. printIn("ignorableWhitespace: [" + s+ "]"); 


/*#* 
* This method will report an entity that is skipped by the parser. 
* This should only occur for non-validating parsers, and then is still 
* implementation dependent behavior. 
* @param name Entity name 
* @throws SAXException when things go wrong 
*/ 
public void skippedEntity (String name) throws SAXException 


{ 
System.out printIn("Skipping entity "+ name); 


} //end of inner class UAN NetworkTopologyContentHandler 
[e* 
* Inner class <em>MyErrorHandler</em> implements the SAX 
* ErrorHandler interface. 
=f 
class MyErrorHandler implements ErrorH andler 


{ 
/*#* 
* Reports a warning that has occurred; this indicates that while 
*no XML rules were "broken", something appears to be incorrect or 
* missing an entity that is skipped by the parser. 
* @param exception Parser exception 
* @throws SAXException 
*/ 
public void warning (SAXParseException exception) throws SAXException 
{ 
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System.out printIn("**Parsing Warning**\n" + 
"Line: "+ exception. getLineNumber() + "\n" + 
"URI: "+ exception. getSystemIdQ + "\n" + 
" Message: "+ exception. getMessage()); 

throw new SAXException("Warning encountered" ); 


} 


[e* 

* Reports an error if a non-critical parsing error has occurred. 

* This error indicates that even if an XML rules was broken, the 

* parsing can continue. 

* @param exception Parse exception 

* @throws SAXException 

*/ 

public void error (SAXParseException exception) throws SAXException 


System. out. printIn("**Parsing Error**\n" + 
"Line: "+ exception. getLineNumber() + "\n" + 
"URI: "+ exception. getSystemIdQ + "\n" + 
" Message: "+ exception. getMessage()); 

throw new SAXException("Error encount ered" ); 


/*#* 
* Reports a fatal error if a critical parsing error has occurred. This 
* fatal error indicates that the parsing process can't continue because 
* of a major violation to XML rules. 
* @param exception Parse exception 
* @throws SAXException 
*/ 
public void fatalError (SAXParseEx ception exception) throws SAXException 
{ 
System. out. printIn("**Parsing Fatal Error**\n" + 
"Line: "+ exception. getLineNumber() + "\n" + 
"URI: "+ exception. getSystemIdQ + "\n"+ 
" Message: "+ exception. getMessage()); 
throw new SAXException("Fatal Error encountered"); 
} 
}//end of inner class MyErrorHandler 
}//end of class SAXNetworlnfoParser 


Te SendDelayThread.java 
package UAN.Sim; 


import UAN. Helpers. Packet; 
import java.io. IOException; 
/*%* 

* This thread delays the sending of the <code>Packet</code> until the first 

* bit would have arrived based on the propogation delay. Uses the java sleep 
* system call to implement the delay. 

*/ 

public class SendDelayThread extends Thread 


SimCommsThread commsThread; 
Packet packet; 
int delay; 
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long temp; 
[e* 


* Constructor 
* 
* @param t the <code>SimCommsThread</code> to send to. 
* @param p the <code>Packet</code> to be sent. 
* @param d the <code>Integer</code> representing the delay in milliseconds. 
my 
public SendDelayThread(SimComms Thread t, Packet p, int d) 
{ 


commsThread = t 


packet =p; 
delay =d; 
} 
[** 
* Thread implementation for run 
*/ 
public void run() 
{ 
try 
{ 


System. out. println("Delay "+delay+ 
"ms before sending packet from "+ 
packet. getSrcName()); 
temp = System.currentTimeMillis() - packet. getSendTime(); 
Thread. sleep(delay - (int)temp); 
} catch (Interrupt edException ex) { 
ex. printS tackTrace(); 


} 
commsThread. dataToNode(p ack et); 


} 
} 


UAN.NODE PACKAGE 
1. NodeControl.java 
package UAN. Node; 


import UAN.Channels. Channel; 
import UAN.Sim.Nodelnfo; 
import UAN. Helpers. Address; 
import UAN. Helpers. Packet; 
import UAN. Helpers. Payload; 
import java.awt.event.*; 

import java.net.*; 

import java.io. * 

import java.util. *; 

import javax.swing. JFrame; 


* Handles all aspects of the simulation node. 
eh 
public class NodeControl 


{ 


static final boolean BASE = true; 
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[e* 
*used as amonitor for transmit and CD threads. No specifier to restrict 
* access to this package. 
*/ 
static boolean receivingBase = false; 
[e* 
*used as amonitor for transmit and CD threads. No specifier to restrict 
* access to this package. 
e/ 
static boolean transmitingBase = false; 
[** 
* used for testing demonstration only 
*/ 
public final static String BROADCAST _ID = "ALL"; 
[e* 
* TCP port number for nodes to connect to <code>SimControl</code> 
*/ 
private static int adminPort = 2875; 


[*e* 

* The IP address of <code>SimControl</code> 

*/ 
private static String simIP = "192.168.1.1"5 //default 
[e* 


* Communication from <code>SimControlk</code> to <code>NodeC ontrol</code>. 
* 
ee static ObjectInputStream oisSim; 
OK 
. Communication from <code>NodeControl</code> to <code>SimControk/code>. 
* 
oe static ObjectOutputStream oosSim; 
eK 
“ This node's info 
4 
private static NodelInfo nodeInfo = null; 
4K 
% Handles communication from node to layer 2 protocol. 
* 
ae static Layer2ThreadR eceive receiveTh read; 
Ok 
% Handles communication from layer 2 protocol to node. 
* 
ae static Layer2Thread Transmit transmitThread; 
OK 
- The transmission rate of the base channel. 
* 
shail static long baseTransmitRate; 
Ok 
a The unique ID associated with the base channel 
* 
aie int baseChannelID; 
[e* 
* The user name of this base channel 
* 
suf static String baseChannelName; 
[e* 


* This node's base channel 
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*/ 
private static Channel baseChannel = null; 
[e* 
* This node's secondary channels 
*/ 
private static Channel[] secondaryChannels = = new Channel[10]; 
[e* 
* The hashtable to contain the thread list of the collision detection 
* threads running for each channel 
*) 
private static Hashtable collisionThreadList = new Hashtable(); 
/*#* 
* A reference for a collision detection thread 
*) 
private static CollisionDetectionThread cdThread; 
/ 7K 
* Main 
* @param args is args 
#/ 
public static void main(String[] args) 
{ 
Socket simSocket = null; 
Payload payload = null; 
Packet packet; 
int packetT ype; 
String tempPort = null; 


BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); 
System.out. println("\nEnter the Sim Control Host IP address <ENTER>::default"); 
try { 

simIP = br.readLine(). trim(); 


if(simIP. lengthO<7) 
{ 

simIP = "192.168.1.1"5 
} 


System.out printIn("\nEnter the Sim Control Host TCP port number <ENTER>::default"); 
tempPort = br.readLine(). trim(); 

} 

catch (IOException ex) 

{ 
System.out printIn("User input invalid"); 

} 


try { 
adminP ort = Integer. parse Int(tempP ort); 


catch(Exception e) 


//do nothing, using default port number 
System.out printIn("Using default port number"); 


} 


try { 

//ouild I/O :: output must be first 

simSocket = new Socket(simIP, adminPort); 
} catch (UnknownHostException ex) { 

ex. printS tackTrace(); 
} catch IOException ex) { 
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ex. printStackTrace(); 


} 


try { 
oosSim = new ObjectOutputStream(simS ocket. getOutputStream()); 
} catch (IOException ex) { 
ex. printS tackTrac e(); 
} 
try { 
oisSim = new ObjectInputS tream(simS ocket. getInputS tream() ); 
} catch (IOException ex) { 
ex. printS tackTrac e(); 


} 

System.out.println("Node connected to IP "+simIP+" and port "+ 
adminPortt" from IP "+simSocket. getLocalAddress()+ " on port "+ 
simSocket.getLocalP ort()); 


try { 
while((packet = (Packet) oisSim.readObject()) != null) 


{ 
payload = (Payload) packet. getPayload(); 
packetType = packet. getPacketType(); 
Thread cdThread; 


if(packetT ype == Packet. DATA) 
{ 
collisionDetection(packet); 
} 
else if(packetType == Packet. LAYER2) 


Address address = (Address)payload. getDat a(); 
connectLayer2 (address); 


} 
else if(packetType == Packet. NODEINFO) 


nodeInfo = (NodelInfo)payload. getD ata(); 
try{ 
buildNode(Q); 
}catch (Exception e){ 
e. printS tackTrac e(); 


startCollisionDetectionThreads(); 
} 
else if(packetType == Packet.SIM) 
if(payload. getData(). toS tring(). trim(). equals("Quit")) 


System. exit(0); 
} 


} 

}//end while 

} catch (ClassNotFoundException ex) { 
ex. printS tackTrac e(); 

} catch (IOException ex) { 
ex. printS tackTrac e(); 

}//end while 

}//end main 
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[e* 
* Gives this packet to the collison detection thread for the channel 
* from which the originating node transmitted. 
*/ 
private static void collisionDetection(Packet packet) 
{ 
Channel thisChannel; 
long duration; 
if(packet. getChannelID() == baseChannelID) 


cdThread = (CollisionDetectionThread) collisionThreadList. get(bas eChannelN ame); 
duration = cdThread.check(packet, baseTransmitRate); 
} 


else 


thisChannel = (Channel) secondaryChannels[packet. getChannelI DQ) ]; 
cdThread = (CollisionDetectionThread) collisionThreadList. get(thisChannel. getName()); 
duration = cdThread.check(packet, getChannelRate(p acket. getChann elID())); 

} 


/** 
* Starts a seperate collison dectection thread for each channel. 
*/ 
private static void startCollisionDetectionThreads() 
{ 
CollisionDetectionThread myThread = new CollisionDetectionThread(BASE); 
myThread. start(); 
collisionThreadList. put(baseChannelN ame, myThread); 


Enumeration enumSecChannels = nodelnfo. getS econdaryChannels().elements(); 
Channel thisChannel; 
while(enumS ecChannels.hasMoreElements()) 
: 
myThread = new CollisionDetectionThread(!BASE); 
my Thread. start(); 
thisChannel = (Channel) enumSecChannels.nextElement(); 
collisionThreadList.put(thisChannel. getName(), myThread); 
} 
} 
/*#* 
* Builds this node from the nodelnfo object 
4 
private static void buildNode() 
{ 
baseChannel = nodelnfo. getBaseChannel(); 
baseChannelID = baseChannel. getIDQ); 
baseChannelName = baseChannel. getName(); 
baseTransmitRate = baseChannel. getTransmitRate(); 
Enumeration sc = nodelnfo. getS econdaryChann els(). elements(); 
Channel thisChannel; 
while(sc. hasMoreElements() ) 


thisChannel = (Channel) sc.nextElement(); 
secondaryChannels[thisChannel. getID()] = thisChannel; 
} 
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System.out println("This Node's name is "+nodeInfo. getNodeN ame()); 
}//end buildNode 
/*#* 
* Returns the transmit rate of a channel with this ID 
* @retum the transmit rate 
*/ 
private static long getChannelRate(int ID) 
{ 
Channel channel = (Channel) secondaryChannels[ID]; 
retum channel. getTransmitRate(); 
}//end getChannelRate 
/*#* 
* Connects to the address received and then spawns a thread to handle the 
* output stream and a seperate thread to handle the input stream. Output 
* and input are relative to layerl's relation to layer2. 
* @param address the <code>Address</code> of the layer 2 protocol host 
*) 
private static void connectLayer2(Address address) 
{ 
//address from layer2 request 
InetAddress layer2IP = address. getIP(); 
int layer2Port = address. getP ort(); 
DatagramSocket dgSkt = null; 
DatagramPacket dgPkt =null 
ServerSocket ss = null; 
Socket skt = nul; 
ObjectInputStream oisL2 = null; 
ObjectOutputStream oosL2 = null; 
try { 
ss = new ServerSocket(0); 
} catch (IOException ex) { 
ex. printS tackTrac e(); 
System. out. println("Could not make new Server Socket in connectLay er2"); 
} 
try { 


dgSkt = new DatagramSocket(ss.getLocalP ort()); 
} catch (SocketException sx) { 
sx. printS tackTrace(); 
System.out printIn("Could not make the datagram socket on the tcp port in 
connectL ayer2" ); 
} 
dgPkt = new DatagramPacket (new byte[0], 0, layer2IP, layer2Port); 
try { 
dgSkt.send(dgPkt); 
} catch(IOEx ception ex) { 
ex. printS tackTrace(); 
System.out printIn("Could not send Datagram to layer2 App in connectLayer2"); 
} 
try { 
skt = ss.accept(); 
} catch (IOException ex) { 
ex. printS tackTrace(); 
System.out printIn("Could not make connection from Server Socket in connectLay er2"); 
} 
try { 
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oisL2 = new ObjectInputStream(skt. getInputS tream()); 
} catch IOException ex) { 
ex. printS tackTrace(); 
System.out println("Could not get input stream in connectLayer2"); 
} 
try { 
oosL2 = new ObjectOutputS tream(skt. getOutputStream()); 
} catch (IOException ex) { 
ex. printS tackTrac e(); 
System.out printIn("Could not get output stream in connectLayer2"); 


receiveThread = new Layer2ThreadReceive(oosL2); 
transmitThread = new Layer2ThreadTransmit(oisL2, baseTransmitRate); 
receiveThread.start(); 
transmitThread. start(); 
}//end connectLayer2 
/*#* 
* Sends packet to layer 2 thread. 
* @param packet the <code>Packet</code> to being sent. 
*/ 


public synchronized static void receiveD ata(Packet pack et) 
{ 
receiveThread.send( (Payload) packet. getPayload()); 
}//end receiveData 
/#* 
* Called from <code>Layer2ThreadT ransmit</code> to pass data from layer2 
* to this simulated physical layer. 
* @param p the <code>Packet</code> to being sent. 
#/ 
public static void transmitData(Packet p) 


try { 
oosSim. writeObject(p); 
oosSim. flush(); 

} catch (IOException ex) { 
ex. printS tackTrac e(); 
System.out.println("Unable to write to output stream in transmitData"); 

} 

}//end transmitData 
}//end NodeControl 


2. CollisionDetectionThread.java 
package UAN. Node; 


import UAN. Helpers. Packet; 
/[#* 
* Handles the collision detection logic for all packets received by a given 
* node. 
*/ 
public class CollisionDetectionThread extends Thread 
{ 
//state can be 0, 5, or 7 respresentation of three bits 
// [busy, collision, message] 
//state 0 is no message in que for decission 
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//state 5 1s message in wait with no collision yet 

//state 7 is message in wait and collision has accured 
//state 9 1s waiting on a transmission window to expire 
final static int IDLE = 0; 

final static int BUSY = 5; 

final static int COLL = 7; 

final static int TRAN = 9; 


int state; 
long collisionWindow, tempTime, duration; //milliseconds 
Packet waitPacket; 
boolean base; 
/*#* 
* Creates a new instance of CollisionDetectionThread 
* 
public CollisionDetectionThread (boolean bas e) 


state = IDLE; 

collisionWindow = tempTime= System.currentTimeMillisQ); 
waitPacket = null; 

this. base = base; 


} 


[e* 
* Thread implementation for run and maintains the states of logic 


* conceming the collision detection algorithm for a full duplex modem. 
*) 
public void runQ) 


while(true) 
if(System.currentTimeMillis() <= collisionWindow) 
if(base) 
{ 


NodeControl.receivingBase = true; 
, 
} 


else 


{ 
if(base) 
{ 


NodeControl.receivingBase = false; 
} 
if(state == BUSY) 


NodeControl.receiveData(waitP ack et); 
state = IDLE; 


else if(state == COLL) 


//drop packet 

System.out.println("Packet Collided(rec) and Dropped from: " + 
waitPacket. getSrcName()); 

state = IDLE; 


} 
else if(state == TRAN) 
77 


//no received pack et had window longer than the transmit window 
state = IDLE; 
} 


yieldQ); //minimizing busy wait 
} 
} 
[*e* 
* Does the overlap checking for all packets and sets the state accordingly. 
* If a packet is involved in a collision, it is dropped and not passed on. 
* @param packet the <code>Packet</code> in question 
*/ 
public long check(Packet packet, long transRate) 


//payload size is in bytes(8 bits) and 1000 is to turn into millieseconds 
//duration is in milliseconds 

duration = (long)((float)(packet. getPayloadSize()*8)/transRate* 1000); 
System.out.println("Transmission Delay is "+ duration); 

if(state == IDLE) 


waitPacket = packet; 


collisionWindow = System.currentTimeMillis(Q) + duration; 
state= BUSY; 


} 

else if((state == BUSY) || (state == COLL)) 

{ 
tempTime= System.currentTimeMillis() + duration; 
if(tempTime > collisionWindow) 


collisionWindow = tempTime; 

System.out.println("Packet Collided(rec) and Dropped from: "+ 
waitPacket. getSrcName()); 

waitPacket = packet; 

//drop original packet that collided 


else //window not longer but still collided 


//drop this packet that collided 


System.out.println("Packet Collided(rec) and Dropped from: "+ 
packet. getSrcName()); 


} 
state= COLL; 
} 
else if (state== TRAN) 


tempTime= System.currentTimeMillis() + duration; 
if(tempTime > collisionWindow) 
{ 
collisionWindow = tempTime; 
System.out printIn("Packet Collided(trans) and Dropped from: " + 
packet. getSrcName()); 
waitPacket = packet; //drop original packet that collided 
state= COLL; 
} 
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else 
{ 
System.out printIn("Packet Collided(trans) and Dropped from: " + 
packet. getSrcName()); 
i 
} 


return duration; 
}//end check 


[*e* 
* need comments 
* 
* not yet called from anywhere 
*/ 
void setTransmitWindow(long window) 


collisionWindow = window; 
state= TRAN; 
} 
} 


3: Layer2ThreadReceive.java 
package UAN. Node; 


import UAN. Helpers. Payload; 
import java.io. IOException; 
import java.io. ObjectOutputStream; 


[e* 

* Handles the communication from <code>NodeControl</code> to the layer 2 
* protocol application over a TCP socket. 

*/ 
public class Layer2ThreadReceive extends Thread 


{ 


/*#* 
* OOS used 
*/ 
private ObjectOutputStream oos; 
/** 
* Constructor 
* @param oos the <code>ObjectOutputS tream</code> 
*/ 
public Layer2ThreadReceive(ObjectOutputStream oos) 
‘ 
this.oos = 00s; 
}//end constructor 
/*#* 
* Thread implementation for run 
#) 
public void rund) 


while(true) 


//keep alive 
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yieldQ);//minimizing busy wait 


}//end run 
[#* 
* Send the packet to the output stream which is contected to a layer 2 
* protocol. 
* @param payload the <code>Payload</code> to send. 
*/ 


public void send(Payload payload) 
{ 
try 
{ 
oos. writeObject(paylo ad); 
} catch (IOException ex) { 
ex. printS tackTrace(); 


} 
}//end send 
}//end Layer2ThreadReceive 


4. Layer2ThreadTransmit.java 
package UAN. Node; 


import UAN. Helpers. Packet; 
import UAN. Helpers. Payload; 
import java.io. IOException; 
import java.io. ObjectInputS tream; 


[re 

* Thread to handle communication between <code>NodeControl</code> and a layer 2 
* protocol application over a TCP socket connection. 

* 


/ 
public class Layer2ThreadT ransmit extends Thread 
{ 
[e* 
* This input stream from the layer 2 protocol. 
*/ 
private ObjectInputStream ois; 
[e* 
* The payload to handle from the layer 2 protocol. 
*) 
private Payload payload; 
[e* 
* The packet to handle. 
*/ 
private Packet packet; 
[e* 
* used for receivingBase and busy state setting 
*) 
private long transmitWindow = System.currentTimeMillis(); 
[e* 


* The transmission rate of this channel. 
3} 

private long transRate; 

private byte[] byteArray; 
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[e* 
* Constructor 
* @param ois the <code>ObjectInputS tream</code> 
*/ 
public Layer2ThreadT ransmit(Object InputStream ois, long transRate) 
{ 
this.ois = ois; 
this. transRate = transRate; 


[e* 
* Thread implementation for run 
*) 

public void runQ) 


while(true) 


while(NodeControl.receivingBase) 
{ 
//can not transmit while receivingBase 
yield();//minimizing busy wait 
} 
try 
{ 
NodeControl.transmitingBase = true; 
payload = (Payload) ois.readObject(); 
byteArray = (byte[]) payload. getData(); 
packet = new Packet(Packet. DATA, payload, NodeControl.baseChannelID); 
packet. setPayloadSize(byteArray. length); 
packet.setSendTime(System.currentTimeMillis()); 
NodeControl.transmitData(packet); 
//payload size is in bytes(8 bits) and 1000 is to turn into millieseconds 
/AransmitWindow is in milliseconds 
transmitWindow = (long)((float)(packet. getPayloadSize()*8)/transRate* 1000); 
try { 
Thread. sleep(transmit Window); 
} catch (Interrupt edException ex) { 
ex. printS tackTrace(); 
System.out println("Did not sleep for duration of transmitWindow"); 


NodeControl.transmitingBase = false; 
} catch IOException ex) { 
ex. printS tackTrace(); 
} catch (ClassNotF oundException ex) { 
ex. printS tackTrace(); 


yieldQ);//minimizing busy wait 


C. UAN.HELPERS PACKAGE 
1. Address.java 


package UAN. Helpers; 
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import java.io.Serializable; 
import java.net. InetAddress; 


[ee 
* Wraps an IP and port number so that it can be passed as on object in an 
* an input or output stream within the simulation. 

*/ 
public class Address implements Serializable 


{ 


[e* 
* TP address 
*) 
private InetAddress IP; 
[e* 
* Socket Port number 
*/ 
private int Port; 
[re 
* Constructor 
* @param ip the <code>InetAddress</code> 
* @param port the <code>Integer</code> representing the port number. 
*) 
public Address(InetAddress ip, int port) { 


IP = ip; 
Port = port; 


} 


[** 
* Get the IP address 

* @retum the <code>InetAddress</code> 
*/ 

public InetAddress getIP() 

{ 


return IP; 


} 


[e* 

* Get the port number. 

* @retum the <code>Integer</code> port number. 
*/ 

public int getPort() 

{ 


retum Port; 


} 


2 Layer2Connect.java 
package UAN. Helpers; 

import java.io. * 

import java.net.*; 


[e* 
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* Layer2Connect is an importable helper class for applications that want to 

* connect to the UAN simulation. These applications are assumed to handle 

* OSI stack functionality of at lease layer 2. This class will make and 

* maintain the connection to the simulation. It presents a send() and 

* receive() method calls for layer to layer interface. This class also 

* performs the data format translation needed from layer 2 to simulation and 

* vice versa. This class receives and returns a byte array. 

*/ 

public class Layer2Connect implements Serializable 

{ 
// variables used to establish interface to the Physical Layer simulation 
private static DatagramSocket dgSocket; // used to request host address 
private static String IP ="192.168.1.1"; // address of Central Host (CH) 
private static int port = 3282; // datagram port to which CH is listenting 
private static DatagramPacket dgPacketl; // datagram to PHY requesting host 
private static DatagramPacket dgPacket2; // datagram from PHY w/address 
private static Socket tcpSocket; // Interface w/host 
private static Payload payload; 
private static Packet packet; 
private static byte[] byteArray; 


// Object streams through which to exchange wrapped packet 

//with the physical layer simulation 

private static ObjectInputStream ois; 

private static ObjectOutputStream oos; 

// input stream with which to interface with the application user 

static BufferedReader br; 

/*#* 

* This class is a helping class for applications to request a connection to 
* the UAN Simulation. This application is expected to act as a layer 2 
* process. This class is offered as an importable class that can be 

* instantiated in order to establish communications with the simulation. 
*Ttis intended to completely abstract the connection implementation but 
*uses TCP sockets. 


4 

public Layer2Connect () throws UnknownHostException, 
IOException 

{ 


br= new BufferedRead er(new InputStreamRead er(System.in)); 

// Establish interface to Servicing "modem" Host 

// 1, Get Central Host (CH) IPAddress and port number from user 
System.out.println("Enter CentralHost IP: <enter for default> "); 
IP = brreadLine().trimQ; 

if(P. length0<7) 


IP = "192.168.1.1"; //default CH 
} 


System.out.println("Enter CentralHost port: <enter for default> "); 


try { 
port = Integer. parseInt(br.readLine(). trim()); 
}catch (Exception e) 


port = 3282; //default port 


} 
dgSocket = new DatagramSocket(); 
System.out printIn("dgSkt port "+ 
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dgSocket. getLocalPort()+" "+ dgSocket. getPort()); 


// - empty UDP packet serves as query to CH 
dgPacket1 = new DatagramP ack et( 

new byte[0], 0, InetAddress.getByName(IP), port); 
dgSocket.send(dgPacket 1); 


// - receive response from CH and extract host information 
dgPacket2 = new DatagramPack et(new byte[0], 0); 
dgSocket.receive(dgP ack et2); 
System.out println("Servicing \"modem\" host: "+ 
dgPacket2. getAddress() + 
"Port: "+ dgPacket2. getPort()); 


// instantiate a TCP connection using the query information 
tepSocket = new Socket(dgPacket2. getAddress(), dgPacket2.getPort()); 


// instantiate i/o stream to sent/receive information 
/Ahrough the "modem" host 
oos = new ObjectOutputStream(tcpS ocket. getOutputS tream()); 
ois = new ObjectInputStream(tcpS ock et. getInputS tream()); 
} 
[e* 
* This method is the interface for layer 2 to pass data to the 
* simulation. 
* @param in is a byte array from the upper layer (assumed layer 2) 
#) 
public void send(byte[] in) 


payload = new Payload(in); 
eee 
oos. writeObject(paylo ad); 
} catch (IOException ex) { 
ex. printS tackTrac e(); 
} 
} 
[e* 
* This method is the interface for layer 2 to get data from the simulation. 
* @retum byteArray a byte array is returned 
*/ 
public byte[] receive() 
{ 


try { 
payload = (Payload) ois.readObject(); 
} catch (ClassNotFoundException ex) { 
ex. printS tackTrace(); 
} catch IOException ex) { 
ex. printS tackTrace(); 


} 
byteArray = (byte[]) payload. getData(); 
return byteArray; 
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3. Packet.java 
package UAN. Helpers; 


import java.io.Serializable; 
/** 
* This <code>Pakcet</code> is the data the packet that is passed within the VAN 
* simulation. Its data types have bearing on the different functions with the 
* logic of <code>NodeControl</code> and how each packet is handled. 
=e) 
public class Packet implements Serializable 


{ 
[e* 
* Packet type if payload received from layer 2 protocol. 
*/ 
public final static int DATA =11; 
[e* 


* Packet type only sent from <code>SimControl</code> to define nodes. 
*/ 
public final static int. NODEINFO = 22; 
[e* 
* Packet type only sent from <code>SimControl</code> to initiate 
* a connection to the defined layer 2 protocol. 


*/ 
public final static int. LAYER2 = 33; 
/#* 
* Packet type only sent from the <code>TestSend</code> class mainly for 
* testing, 
ef 
public final staticint SIM =44; 
/** 
* The packet type of this packet. 
*/ 
private int packetType; 
[e* 
* The payload size within this packet. 
eh 
private int payloadSize; 
[e* 
* The time this packet was sent. Used to calculated simulated propogation 
* delay. 
*/ 
private long sendTime; 
/*#* 
* The payload contained withing this packet. 
*/ 
private Payload payload; 
/#* 
* String names for destination and source node name 
*) 
private String destName, srcName; 
/*#* 
* Channel that this packet transmitted in 
*) 
private int channelID; 
/** 


85 


During 


* THIS CONSTRUCTOR USED DURING DEVELOMENT, TESTING AND SETUP. 


* simulation runs, the destintation will not be a function of this layer. 
* Only the source will matter in this simulation so that broadcast 
* neighborhoods can be determined. 
* @param type the <code>Integer</code> representation of packet type 
* @param payload the <code>Payload</code> in this packet 
* @param destination the destination name as a String 
* @param channel the channel ID 
*/ 
public Packet(int type, Payload payload, String destination, int channel) 
{ 
packetType = type; 
this.payload = payload; 


destName = destination; 
channelID = channel; 
payloadSize = 10; //bytes :: default 
} 
[ee 


* This constructor used for actual environment simulation runs. 
* @param type the <code>Integer</code> representation of packet type. 
* @param payload the <code>Payload</code> in this packet. 
* @param channel the <code>Channel</code> this packet was transmitted on. 
#) 
public Packet(int type, Payload payload, int channel) 
{ 
this(type, payload, null, channel); 


[e* 
* Gets the channel ID 
* @retum the channel ID as an integer 
*/ 
public int getChannelIDQ) 
{ 
return channelID; 


} 


[e* 
* Sets the source node name of this packet 
* @param s the source name 


*/ 
public void setSrcName(String s) 
{ 
srcName = s; 
} 
[e* 


* Gets the source name. 
* @retum the name of the node that sent this packet. 
*/ 

public String getSrcName() 


return srcName; 


} 


[e* 
* Gets the payload from this packet. 
* @retum the payload carried by this packet as a UAN <code>Payload</code> object. 
*/ 
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public Object getPayload() 


return payload; 


[e* 
* Gets the payload size carried by this packet. 
* @retum the payload size in this packet. 

*/ 

public int getPayloadSize() 

{ 


return payloadSize; 


[e* 
* Sets the payload size carried by this packet. 

* @param numBytes is the number of bytes that this payload carries. 
my 

public void setPayloadSize(int numBytes) 

{ 


payloadSize = numBytes; 


[** 
* Get this packet's type. 

* @retum this packet's type 
*/ 

public int getPacketType() 

{ 


return packetType; 


} 


[** 
* Sets the send time for this packet. 
* @param time the send time milliseconds 


*/ 
public void setSendTime(long time) 
{ 
sendTime = time; 
} 
[ee 


* Gets the sending time of this packet. 


* @retum the send time of this packet in milliseconds. 

*/ 
public long getSendTimeQ) 

return sendTime; 

[RR Testing Methods 9 #28 #9 9 3 9 9 A RA EI EE A I AE EC / 
[e* 

* Gets the destination node name for this packet. Only set and used in 

* testing and demonstrations of logic. 

* @retum the destination node name. 


*/ 
public String getDestName() 


return destName; 


} 
}//end packet 
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4. Payload.java 
package UAN. Helpers; 


import UAN.Sim.Nodelnfo; 
import java.io.Serializable; 


/** 
* Used as a wrapper for any payload defined. Abstracts for the rest of the 
* simulation. Payload type only need to be defined here. 
*/ 
public class Payload implements Serializable 
{ 
Object 0; 
[e* 
* String Constructor 
* @param s the <code>String</code> to be the payload. 
*/ 
public Payload(String s) { 
Oo=S 
} 


/*#* 
* Nodelnfo Constructor 
* @param node the <code>Nodelnfo</code> to be the payload. 
*) 
public Payload(NodeInfo node) { 
o= node; 


/*#* 
* Integer Constructor. 
* Converted to a String, 
* @param num the <code>Integer</code> to be the payload. 
*/ 
public Payload(int num) 
{ 


String snum = Integer. toS tring(num); 
o= snum; 


[e* 


* Address Constructor. 


* @param address the <code>Address</code> to be the payload. 
*/ 


public Payload(Address address) 


o= address; 


[e* 
* Byte Array constructor used by the simulated layer 2 application. 
* @param myByte the <code>byte[]</code> to be the payload. 
*/ 
public Payload(byte[] in) 
{ 
o= in; 


} 
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[re 
* Gets the object that is payload. 
* @retum the object in the payload. 
*/ 

public Object getData() 


return 0; 


} 
} 


5. UAN Net.dtd 


<?xml version="1.0" encoding="UTF-8"?> 
<!-- 


> 
<!-- PCDATA stands for Parsed Character Data and it means that the element contains text data" - 


<!ELEMENT NodeName (#PCDATA)> 

<!ELEMENT NodeType (#PCDATA)> 

<!ELEMENT NodeLocation (#PCDATA)> 

<!ELEMENT NodeDepth (#PCDATA)> 

<!ELEMENT ChannelID (HPCDATA)> 

<!ELEMENT ChannelName (#PCDATA)> 

<!ELEMENT Channel (ChannelName, ChannelID )> 

<!ELEMENT Node (NodeName, NodeType, NodeLocation, NodeDepth, Channel+)> 
<!ELEMENT UAN_ Net (Nodet+)> 


6. UAN4node.xml example 


<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE UAN_Net SYSTEM "UAN net.dtd"> 
<UAN_Net> 
<Node> 
<NodeName>NodeA</NodeNam e> 
<NodeType>Static</NodeType> 
<NodeLocation>32 -96</NodeLocation> 
<NodeDepth> 10</NodeDepth> 
<Channel> 
<Channel Name>NodeAb ase</ChannelN ame> 
<ChannelID>0</ChannelID> 
</Channel> 
<Channel> 
<ChannelName>NodeAs ecl</ChannelN ame> 
<ChannelID> 1</ChannelID> 
</Channel> 
</Node> 
<Node> 
<NodeName>NodeB</NodeName> 
<NodeType>Static</NodeType> 
<NodeLocation>32 -96.01</NodeLocation> 
<NodeDepth> 10</NodeDepth> 
<Channel> 
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<ChannelName>NodeBbas e</ChannelName> 
<ChannelID> 1</ChannelID> 
</Channel> 
<Channel> 
<ChannelName>NodeBsecl </ChannelName> 
<ChannelID>0</ChannelID> 
</Channel> 
<Channel> 
<ChannelName>NodeBsec2</ChannelName> 
<ChannelID>2</ChannelID> 
</Channel> 
</Node> 
<Node> 
<NodeName>NodeC</NodeName> 
<NodeType>Static</NodeType> 
<NodeLocation>32 -96.015</NodeLocation> 
<NodeDepth> 10</NodeDepth> 
<Channel> 
<Channel Name>NodeCbas e</Channel Name> 
<ChannelID>0</ChannelID> 
</Channel> 
<Channel> 
<Channel Name>NodeCsecl</ChannelName> 
<ChannelID> 1</ChannelID> 
</Channel> 
<Channel> 
<Channel Name>NodeCsec2</Channel Name> 
<ChannelID>2</ChannelID> 
</Channel> 
</Node> 
<Node> 
<NodeName>NodeD</NodeNam e> 
<NodeType>Static</NodeType> 
<NodeLocation>32.008 -96.01</NodeLocation> 
<NodeDepth> 10</NodeDepth> 
<Channel> 
<Channel Name>NodeDb ase</ChannelN ame> 
<ChannelID>2</ChannelID> 
</Channel> 
<Channel> 
<ChannelName>NodeDs ecl</ChannelN ame> 
<ChannelID>0</ChannelID> 
</Channel> 
<Channel> 
<ChannelName>NodeDs ec2</ChannelN ame> 
<ChannelID> 1</ChannelID> 
</Channel> 
</Node> 


</UAN_Net> 


UAN.CHANNELS PACKAGE 


Channel.java 


package UAN. Channels; 
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import java.io.Serializable; 


[e* 
* Superclass for all channels with each instantiation representing a set of 
* atrributes that defines a transmit and receive capability and limitation. 
*/ 
public class Channel implements Serializable 
{ 
[e* 
* Constant for kilobits per second 
*) 
static final int Kbps = 1000; 
[e* 
* Transmision rate for this channel 
*/ 
private int transmitRate; 
[e* 
* Frequency for this channel 
o) 
private int frequency; 
[e* 
* User designated name for this channel 
*/ 
private String name = null; 
[e* 
* Unique ID for this channel 
*/ 
private int ID; 
[e* 
* Constructor 
* @param name is the user asigned name of this channel. 
* @param transmitRate is the tranmission rate of this channel. 
* @param frequency is the frequency of this channel. 
* @param ID is the unique channel ID of all channels defined. 
*/ 
public Channel(String name, int transmitRate, int frequency, int ID) 
{ 
this.name = name; 
this.transmitRate = transmitRate; 
this.frequency = frequency; 
this.ID = ID; 
} 


[e* 
* gets the transmission rate of this channel. 
* @retum the transmission rate. 

#/ 

public int getTransmitRate() { 

retum transmitRate; 


/*#* 
* gets the frequency of this channel. 
* @returm the frequency. 
*) 
publicint getFrequency() { 
return frequency; 


} 
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[** 
* gets the user asigned name of this channel. 
* @retum the discriptive name of this channel set by the user. 
*/ 
public String getName() { 
return name; 


[e* 


* get the unique ID of this channel compared to all defined channels. 
* @retum the unique ID of this channel. 

*/ 

public int getIDOQ 

{ 


retum ID; 


} 
} 


2. ChannelZero.java 
package UAN.Channels; 


[e* 
* Instantiation of ChannelZero 
"ef 
final public class ChannelZero extends Channel 


{ 


[e* 
* Constructor 
oh 

public ChannelZero(String name) 


{ 
super(name, 1*Kbps, 4, 0); 
} 


} 


3. ChannelOne.java 
package UAN.Channels; 


[e* 
* 
* Instantiation of ChannelOne 
e 
final public class ChannelOne extends Channel 


{ 


[e* 


* Constructor 
*/ 
public ChannelOne(String name) 


{ 
super(name, 1*Kbps, 1, 1); 
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4. ChannelTwo.java 
package UAN. Channels; 


[e* 
*Instatiation of ChannelTwo 
*/ 
final public class ChannelTwo extends Channel 


{ 


[e* 
* Constructor 
*/ 
public ChannelTwo(String name) 


{ 
super(name, 1*Kbps, 6, 2); 


} 
} 
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